Skip to main content
Your vendor runs their software inside your environment. Routine support can use vetted, reviewable commands rather than standing SSH keys, a kubectl context or a database password. Occasionally, your vendor needs to reach one 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 gives you a request to review for one resource and an approved session duration. You sign approval with your own key or reject the request. Where a connector is needed, you also review and apply its bundle in your environment. You can end an active session and follow its cleanup; ending does not prove that every credential or resource was deleted.

​
What break glass is, and your role

Reaching a resource takes two things: a network path and a credential. Review which of these break glass supplies, because their preparation, expiry and cleanup differ.
  • The network path. Direct access uses an already reachable resource. A connector session uses a reviewed Tailscale or Twingate placement. You apply its bundle using your own cloud credentials and destroy it during cleanup (see Preparing your network).
  • The credential. The controller can supply a credential, or an approved operational command can generate or fetch one. A Kubernetes token has a native expiry; a recipe credential may rely on its revoke action instead. With an out-of-band credential, your vendor authenticates with a credential they already hold. Break glass does not manage that credential’s lifetime or permissions.
Your role is to approve and govern the requested access. The controller verifies your signature against your pinned public key before supplying a credential. You separately control whether to apply a connector bundle and how your network permits it to reach resources. See Security Model for the broader relationship with your vendor. 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 requests access to one resource for an approved session window. That deadline starts cleanup; a credential’s native expiry is a separate property. 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

Your vendor shares the request’s approval link through your existing communication channel. Opening it shows you the request to review: You then approve or reject.
1

Review the scope

Review the resource, privilege, duration, network placement and any credential recipe against the questions below. An out-of-band credential’s existing permissions remain separately managed.
2

Decide

Reject to stop it cold (you can include a reason, which is sent back to your vendor), or continue to approve.
3

Sign

Approving means signing the request with your own key. The approval page gives you a short script that signs locally; your private key never enters the browser or reaches us. See Signing Keys for the one-time key setup.
4

Verify and activate

Before supplying a credential, the controller verifies your signature against your pinned public key. If the session uses a connector, review and apply its bundle using your own cloud credentials. The session becomes Active only when its required access is ready.
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 current approval format binds the resource, requested privilege and duration, plus recipe code and inputs where applicable. Changing signed fields breaks verification. The approval endpoint accepts approval only while the request is pending and rejects a repeat approval. Credential minting also applies freshness checks appropriate to that path; the signature is not a universally single-use credential. The approved session duration starts at Active, after the required access is ready. Waiting for approval or preparation does not count against that window. A credential can expire earlier, and the session clock does not extend it. Ending a session early. Once the session is Active, use the approval page’s end-session control to request cleanup before the deadline. It moves the session to Ending; cleanup proceeds in the background. This is not a guarantee of immediate disconnection or deletion. Destroy any connector bundle you applied, and follow up on reported cleanup failures and residual resources. Ended means the controller recorded cleanup complete, not independent proof that every identity or resource was deleted.
Ending a break glass session is not the same as revoking access. Revoking access removes a standing permission tier you granted the controller. Ending a break glass session ends one approved session. Both are yours to control; they operate at different scopes.

​
Preparing your network for a private target

A connector session can use a Tailscale subnet router or a Twingate connector. Review its recorded placement and bundle before applying it using your own cloud credentials. Signing the request does not apply that bundle for you. The session becomes Active only once the connector and any supplied credential are ready. This adds a session-specific network path to the posture described under No Inbound Network Access. At session end, break glass attempts to remove provider-side access. You must also destroy the connector bundle you applied. A shipped-bundle session requires teardown confirmation before the controller records Ended.
Review the connector’s placement, routes and resource access alongside your existing network controls. Your vendor operates the tailnet and its access policies; you control the deployment’s network isolation and whether to apply the bundle. A dedicated account, VPC or namespace, as recommended when you set up your environment, helps separate the deployment from other resources. The connector does not replace those controls.

​
Guarantees and audit

Keep these controls and limits distinct:
  • Customer authorization. You sign the access request. Before supplying a credential, the controller checks the signature against your pinned public key. You separately review and apply any connector bundle in your own environment.
  • Resource, privilege and duration. Review the requested resource and privilege. The Kubernetes path grants a cluster-admin-tier credential; this does not mean minimal permissions within the cluster. An out-of-band credential can already have broader permissions. The approved session window starts at Active; native credential expiry depends on its type.
  • Credential handling. A supplied credential is held transiently by the control plane for one fetch. A recipe can generate a fresh credential or fetch an existing one. Expiry and revocation depend on that source; break glass does not revoke an out-of-band credential.
  • Readiness and cleanup. If a brokered mint approval cannot be verified, the controller does not mint that credential. The session does not become Active until its required access is ready. Failed preparation can still need cleanup. Reported cleanup failures are retried and can fail with an alert; residual identities or resources can need follow-up even when a session is recorded complete.
Your audit record. The request, signed approval and cleanup are recorded; credential delivery is logged on a best-effort basis. The approval preserves its signer public key and fingerprint, so you can verify its signature against that embedded key. Establish the signer’s authorization separately by comparing the fingerprint with the key you had pinned at approval time. Preserve that historical key and pin record through rotation; the current pin alone does not establish the historical pin. The controller checks its pinned key before brokered credential minting. A connector-only or out-of-band session does not automatically perform that mint-time check; your authority to review and apply the connector bundle remains separate. Keep the signed record alongside your infrastructure audit (Auditing Permission Changes, e.g. your cloud audit log).