Skip to main content
A break glass session moves from an access request through customer approval, preparation, use and cleanup. This page walks your side of that flow, including the difference between a session ending and the controller recording cleanup complete.

​
Requesting access

You start a request from the Break Glass page in your vendor portal. Pick the appliance and the one resource you need to reach, then submit: Automatic network resolves the path from the resource. You can also select a configured Tailscale or Twingate provider where offered. Break glass validates the access method and connector placement for the target before approval. See Network providers. Once submitted, the request is PendingApproval, shown as Pending Approval in the portal, and your customer’s review begins.
The approved session duration starts at Active, after the required access is ready. Waiting for approval or preparation does not count against that session window. A credential’s own expiry can be earlier; the session clock does not extend it.

​
Session states

The happy path is request, approve, assemble, use, expire. A few terminal states cover the ways a session can stop early. Identity-only sessions can move from Approved directly to Active; they do not provision a connector. Connector sessions use Provisioning and ConnectorDeploying before Active. Terminal states for a session that stopped early: A session goes Active only when its required access is ready. For a connector session with a supplied credential, that means the credential is ready and the connector is online. An out-of-band session supplies only the network path; the operator authenticates with a separately managed credential.

​
What your customer sees

After submitting a request, copy its approval link and share it with your customer through your existing notification channel. Opening it shows the resource, requested privilege, reason and duration. Your customer picks Approve or Reject. Approving means signing the request. Your customer signs with a private key that lives in their own environment and never travels to your control plane; the appliance controller running in their account verifies that signature against a public key only your customer controls before it mints anything.
This is the same signing keypair your customer uses to approve operations commands, so if they’ve used operations, no second signing keypair is needed. See operations security for how the keypair is generated, stored, and pinned.
The current approval format binds the resource, requested privilege and duration, plus recipe code and inputs where applicable. Changing those signed fields breaks verification. The approval endpoint accepts a decision only while the request is pending and rejects a repeated approval. Credential minting also applies freshness checks appropriate to that credential path. For a connector session, your customer reviews and applies the connector bundle using their own cloud credentials. Signing the request does not apply that bundle for them.

​
Using the session

Once the session is Active, break glass delivers what the operator needs to connect:
  • Kubernetes: a ready-to-use kubeconfig for the session. It holds the minted, short-lived credential and the cluster endpoint; point kubectl at it and work normally.
  • Database and other resources: the connection details produced by the approved credential source (for example, a short-lived database login).
  • Out-of-band sessions: break glass delivers the network path so the otherwise-private endpoint becomes reachable, and the operator authenticates with the credential they already hold. Break glass delivers no credential in this case.
A supplied credential is delivered to the operator once (consumed on read) and held transiently by the control plane. Treat those connection details as secret. A credential’s native expiry and its revocation are separate from the session clock; an out-of-band credential remains separately managed.
A minted credential’s lifetime can be capped below the approved duration by your customer’s own environment (for example, a Kubernetes cluster’s maximum service-account token lifetime). If that cap is shorter than your session, the credential can expire mid-session and is not re-minted automatically; request a fresh session if you need more time.

​
Expiry, teardown, and revocation

Session expiry starts cleanup; it does not give every credential a native expiry or prove that every resource was deleted.
  • Credential expiry. Where the credential supports a native expiry, it stops authenticating on its own clock. Other credentials depend on their revoke action. Break glass does not revoke an out-of-band credential.
  • Cleanup. Break glass attempts to revoke access it supplied. Your customer also destroys any connector bundle they applied, and its teardown confirmation is recorded before that shipped-bundle session reaches Ended.
To end an active session early, end it from the Break Glass page. This requests cleanup without waiting for the session deadline; it does not wait synchronously for every resource to be removed. Reported cleanup failures are retried and can fail with an alert. Follow up on reported failures and any residual resources. Ended means the controller recorded cleanup complete, rather than independently proving deletion of every identity or resource.