Skip to main content
Break glass coordinates customer-approved access to one resource for a session. Its security controls depend on the access being supplied: customer-signed approval is verified before a brokered credential is minted, while your customer applies any reviewed connector bundle in their own account. Session expiry, a credential’s native expiry and recorded cleanup completion are separate events.

​
The core guarantee

Your customer signs an approval for a specific request. Before supplying a credential, the appliance controller verifies the approval against your customer’s pinned public key and checks the signed request. A connector session also requires your customer to review and apply its connector bundle using their own cloud credentials.

​
Trust model

The control plane coordinates access; authority in your customer’s account remains with the customer and appliance controller:
  • The vendor control plane coordinates the workflow (it relays the request and the approval, drives the session). It is not trusted to grant access on its own.
  • The appliance controller, running inside your customer’s account under their IAM, checks the pinned signing key and request before supplying a credential.
  • Your customer reviews the connector bundle and applies it with their own cloud credentials. A relayed approval alone does not deploy that infrastructure.
For brokered credential minting, the controller requires approval signed by the pinned customer key. It verifies the signed fields rather than accepting a changed resource, privilege or duration from the control plane. The customer’s private signing key stays in their environment; the control plane relays the approval.

​
The approval is customer-signed

Break glass uses the same customer-signed approval mechanism as operations: your customer signs with an Ed25519 private key that lives in their own environment and never travels to your control plane, and the appliance controller verifies against a public key your customer has pinned into the controller’s secret store. If your customer has already set up signing for operations, no second signing keypair is needed. The mechanics of that keypair (how it’s generated, where the private key lives, how the public key is pinned, and how to rotate it) are documented in the operations security model. Rather than restate them, this page covers what’s specific to break glass.

​
What the approval binds

A break glass approval is a signature over an explicit, fixed set of request fields, not a blanket grant. The signed set is what defines what your customer is consenting to: The current approval format signs these request fields. Changing them alters the signed bytes and fails verification. Before brokered minting, the controller checks the request digest, signature and pinned key; for a credential recipe, it also checks the code it actually loaded against the approved code hash and uses the signed inputs. The approval endpoint accepts approval only while the request is pending and rejects repeated approval. Mint freshness checks depend on the credential path; they are not one universal short window. Cleanup can reuse a signed recipe approval for its revoke action. These checks do not make the signature itself a universally single-use credential. When the credential is produced by an operational command, the approval binds the exact command and its inputs, and the appliance controller re-checks that the command it’s about to run is exactly the one your customer approved before it runs anything. See operations security for how command approval and integrity are signed and verified.

​
Least privilege and time-boxing

A request selects one resource and an approved session duration:
  • Resource and privilege. Brokered minting checks the signed target and privilege. An out-of-band credential can have permissions beyond that request; its existing authorization remains separately managed.
  • Session duration. The session clock starts at Active, after required access is ready. A credential’s own expiry is separate: a Kubernetes token has a native expiry and may be capped below the session duration. A recipe credential may have no native expiry and rely on its revoke action instead.
The approved request does not imply minimal permissions inside the resource: the shipped Kubernetes path, for instance, mints a cluster-admin-tier credential. Review the requested privilege and the credential source. A session deadline is not a universal native expiry for every credential or a guarantee that existing connections terminate.

​
No standing or stored credentials

Credential handling depends on the source:
  • Controller-minted credentials are created for the session. An approved recipe can generate a credential or fetch one that already exists; it is not necessarily a fresh identity.
  • Transient control-plane delivery. A supplied credential is held in memory for one fetch and consumed on read. It is not persisted as credential material on the session record. This does not guarantee that no secret reaches disk or logs inside the customer’s environment: recipes use temporary output files, and local diagnostics can contain recipe output.
  • Expiry where supported. Native expiry is a safeguard for credential types that implement it. It does not replace cleanup or apply to every recipe credential.
  • Cleanup attempts. At session end, break glass attempts to revoke the credential and network access it supplied. Your customer also destroys any connector bundle they applied.
For an out-of-band session, break glass supplies no credential, so it has no target credential to deliver, store or revoke. That credential’s lifetime remains separately managed. Ended means the controller recorded cleanup complete, not independent proof that every identity or resource was deleted. Some identity records can remain after their credential is disabled; other residual resources can need follow-up. Reported cleanup failures are retried and can fail with an alert.

​
Temporary network paths

A connector session uses a reviewed network placement and per-session provider access. Your customer applies the connector bundle in their account. At session end, break glass attempts to remove the provider access, and your customer destroys that bundle. A shipped-bundle session requires teardown confirmation before the controller records Ended; this is distinct from independent proof that every resource is gone. Network-level access control within your own network remains governed by your network configuration. For Tailscale, that means your tailnet’s ACLs, which you control; scope them to match the access you intend break glass sessions to have. See Network providers for how each provider’s path is configured.

​
Fail-closed

If the controller cannot verify a brokered mint approval, it does not mint the credential. A session does not become Active until the access it needs is ready. These admission checks do not prove that a failed preparation attempt left no resources behind. Cleanup is a separate process. Reported failures are retried and can fail with an alert; a credential self-expires only where its type supports expiry. The recorded session state is not independent evidence that every identity or resource was deleted. Follow up on reported failures and residual resources.

​
Audit

The request, your customer’s signed approval, and teardown are recorded; credential delivery is logged on a best-effort basis. The customer-signed approval is the durable, non-repudiable evidence of consent: an Ed25519 signature over the fixed set of approved fields, preserved on the session record and re-verifiable in principle against the customer’s pinned public key. It is the same approval primitive operations uses, though the turnkey tensor9 ops command audit verify tool is specific to operations commands and does not cover break glass sessions today.