Requesting Access

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 specify	Notes
Resource	The single resource the session targets (a cluster, a database, a service). One session reaches one resource.
Reason	Free-text justification. Shown to your customer at approval time and recorded in the audit trail.
Duration	How long you need. This bounds the session and the lifetime of any credential minted for it, measured from when the session becomes active.
Credential source	How the credential is produced for this resource: minted by the appliance controller, minted by an approved operational command, or supplied out of band. Offered only where more than one applies.

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.

State	What it means
Pending	The request exists and is waiting on your customer’s decision. You can withdraw it; it also auto-expires if your customer never acts within the request window.
Activating	Your customer approved. Break glass is assembling the session: minting the credential where break glass supplies one, and (for a private target) bringing the temporary network path online.
Active	Every plane the session needs is ready. You can use the resource. The session carries an expiry derived from the approved duration.
Ended	The session finished. The temporary credential and any temporary network path have been removed.

Terminal states for a session that stopped early:

State	What happened
Rejected	Your customer declined the request at review. A rejection can carry a reason back to you.
Cancelled	You withdrew the request before your customer acted.
Failed	The session couldn’t be fully assembled or torn down (for example, a temporary tunnel never came online). Break glass fails closed: a session that can’t be assembled does not go active.

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.

How break glass works: the two-plane model and where this flow fits.
Network providers: how the network path for a private target is configured.
Security model: the approval, least-privilege, and audit guarantees behind this lifecycle.