Break Glass

Your vendor runs their software inside your environment with no standing access - no SSH key, no kubectl context, no database password. Most support work goes through vetted, reviewable commands. Occasionally, though, your vendor needs to reach one specific resource directly and interactively: a live kubectl session against a crash-looping cluster, or a database connection during an incident - work that can’t be pre-scripted as a single command. Break glass is the consented, time-boxed path for that. Nothing happens without an approval you sign. You review each request, approve or reject it, hold the key that authorizes it, can end a session at any time, and control the network it runs over.

​

What break glass is, and your role

Reaching a resource takes two things: a network path to it, and a credential to authenticate once there. Break glass assembles both, only for the session you approved, and tears them down when it ends.

• The network path. If the resource is already reachable, none is created. If it’s private, a temporary path is stood up into your network for the session and removed at the end (see Preparing your network).
• The credential. For a Kubernetes cluster, the controller mints a fresh, short-lived token, and at session end revokes it by deleting the minted identity behind it (the token also self-expires on its own clock). For most other resources, a credential is produced by an operational command you approve (for example, a script that reads a database password from your secret store or creates a short-lived login). Sometimes your vendor authenticates with a credential they already hold, and break glass only opens the network path.

Your role throughout is to approve and govern all of this: it is your signature that authorizes a session, your key that the controller verifies, the network isolation that bounds a session’s reach, and your decision to end a session early. This is the same posture as the rest of your relationship with the vendor - see Security Model - applied to one-off, hands-on access. This is distinct from the standing permission tiers you grant the controller. Those are broad, ongoing IAM/RBAC grants you toggle on and off. Break glass is a single, cryptographically-approved, self-expiring session scoped to one resource. For routine investigation you might enable an on-demand permission tier and revoke it afterward; break glass is for when the vendor needs direct, bounded access to one specific resource.

​

Reviewing and approving a request

When your vendor requests break glass, you’re notified over your existing channel and given a link to an approval page. Opening it shows you the full request: You then approve or reject. How to decide. Before you approve, ask:

• Does the stated reason justify direct access to this resource?
• Is the privilege level acceptable? Be aware that the Kubernetes path mints a cluster-admin-tier credential - you are signing off on that level of access, scoped to that one cluster for that one session.
• Is the requested duration reasonable for the work?
• Is this a resource you’re willing to expose for a hands-on session right now?

What your signature commits to. The signature covers exactly the fields above and nothing else. After you sign, the request cannot be silently pointed at a different resource, widened in privilege, or extended in duration - any change breaks the signature and the controller rejects it. Approvals are single-use and valid only briefly, so a captured approval can’t be replayed later. The requested duration is the length of the usable session and starts when the session becomes active (after you approve), so time spent waiting on your decision doesn’t count against it. Ending a session early. Once a session is active, you can end it at any time; teardown runs immediately and your vendor loses access. Because the credential also self-expires on its own clock, ending early and letting it lapse reach the same result - no standing access remains.

​

Preparing your network for a private target

If the resource your vendor needs to reach isn’t already reachable, break glass stands up a temporary, session-scoped path into your network - a Tailscale subnet router or a Twingate connector - created with single-use keys and removed when the session ends. It exists only for that one session. This is a deliberate, temporary exception to the otherwise outbound-only posture described under No Inbound Network Access. It is created only after you approve a request, and only for that session.

​

Guarantees and audit

A few properties hold for every session:

• You are the only party that can authorize access. Your vendor’s control plane coordinates the workflow but is not trusted to grant access. The decision is made by the controller in your own account, which verifies your signature against a key only you hold. Even a fully compromised control plane cannot mint access, widen it, redirect it, or extend it - all of those require your key, which is never on the vendor’s side.
• Least privilege means scoped and time-boxed. A session reaches exactly the resource you approved, for the one session, for the duration you approved (your own environment - for example a cluster’s maximum token lifetime - may shorten it further, but never extend it). It does not mean minimal permissions within the resource: the Kubernetes path is cluster-admin-tier. What’s bounded is reach and lifetime, not the privilege level you signed off on.
• Nothing privileged is left behind. Minted credentials are short-lived, delivered to your vendor once, never stored durably, and explicitly deleted at session end along with any temporary network path. Between sessions, nothing break glass created remains in your account.
• Fail-closed. If your signature can’t be verified, or the session can’t be assembled, nothing is minted and the session does not go active. If teardown is interrupted, the credential still lapses on its own clock.

Your audit record. The request, your signed approval, and teardown are recorded; credential delivery is logged on a best-effort basis. Your signed approval is the durable, non-repudiable evidence of what you consented to - an Ed25519 signature over the exact approved fields, re-verifiable against your pinned public key. This sits alongside the infrastructure-level audit you already keep (Auditing Permission Changes, e.g. your cloud audit log).

​

Related

• Signing Keys - set up the key you sign approvals with
• Security Model - the trust boundary this builds on
• Permissions - the standing access tiers, contrasted with a break glass session
• Revoking Access - revoking standing access, and the audit log