Skip to main content
A break glass session moves through a state machine on its way from “I need to get into this resource” to “the session is over and everything is torn down.” This page walks your side of that flow: how to request access, what your customer sees in parallel, how the session is assembled, and how it ends.

​
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: You do not pick the network path. Break glass resolves that from the resource: if the target is already reachable it uses the Direct path; if it’s private it stands up a temporary tunnel through your configured provider. See Network providers. Once submitted, the request is Pending and your customer’s review begins.
The requested duration is the window of usable access, and it begins when the session goes Active (after your customer approves), not at submission. Time spent waiting for your customer to approve does not count against the duration.

​
Session states

The happy path is request, approve, assemble, use, expire. A few terminal states cover the ways a session can stop early. Terminal states for a session that stopped early: A session goes Active only when every plane it needs is ready. For a private target with a minted credential that means the credential is minted and the tunnel is online; if either half can’t complete, the session does not activate. An out-of-band session resolves only the network path (the operator brings their own credential), so it activates once that path is online.

​
What your customer sees

When you submit a request, your customer is sent (via your existing notification channel) a unique support-portal link. Opening it shows the exact request: which resource, the privilege being requested, your reason, and the 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, break glass approvals work immediately. See operations security for how the keypair is generated, stored, and pinned.
The approval is bound to this one request. It cannot be redirected at a different resource, widened in privilege, or extended in duration after your customer signs; any such change breaks the signature. Approvals also have a short validity window and are single-use, so a captured approval can’t be replayed later.

​
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 carries 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 minted credential is delivered to the operator once (consumed on read) and is not durably stored by the control plane. Treat the delivered connection details as the session’s secret: they’re scoped to this one session and expire with it.
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

Access ends when the session ends, and it ends two ways, both bounded:
  • Self-expiry. A minted credential is short-lived, with a lifetime tied to the approved duration. Even if teardown is interrupted, the credential stops working on its own clock.
  • Explicit teardown. At session end, break glass removes what it created: it deletes any minted identity (revoking the credential) and tears down any temporary network path. For an out-of-band session there is no minted credential to revoke, so only the network path is removed. Confirmed teardown is recorded.
To end a session early, end it from the Break Glass page; teardown runs immediately rather than waiting for the expiry. Because the credential also self-expires, ending early and letting it lapse both converge on the same result: no standing access remains.