kubectl session against a crash-looping cluster, or connect to a
database to diagnose a live incident.
Break glass is the surface for one-time, time-bounded access to a single
named resource. You request it, your customer reviews and cryptographically
approves that single request, and the system assembles exactly what’s
needed to reach and authenticate to that resource for the length of the
session. When the session ends, everything is torn down. Nothing
privileged is left standing in your customer’s account between sessions.
When to use break glass
Break glass is deliberately separate from the standing operations channel. Reach for it only when a vetted command isn’t enough:| Use the standing channel | Use break glass |
|---|---|
| Operations: run a vetted template against an appliance and get signed output back | Reach a resource directly for an interactive or open-ended session |
| The work fits in a known, reviewable command body | You need a live shell, a kubectl context, or a database connection |
| No interactive session required | A live incident or deep-debug session where you can’t pre-script every step |
The two planes
Getting an operator onto a customer resource takes two independent things: a network path to reach it, and a credential to authenticate once there. Break glass models these as two planes and resolves each one per target.| Plane | Question it answers | Resolutions |
|---|---|---|
| Network path | How does the operator’s traffic reach the resource? | The resource is already reachable (Direct), or it’s private and break glass stands up a temporary tunnel (Tailscale or Twingate). |
| Credential | How does the operator authenticate once there? | The appliance controller mints one, an approved operational command mints one, or the operator brings their own (out of band). |
How the credential is minted
The credential plane is where most of the variation lives:| Credential source | When it applies | Example |
|---|---|---|
| Appliance controller | The controller has structural authority over the target and can mint a fresh credential itself | A Kubernetes cluster the controller administers: it issues a new, per-session, short-lived ServiceAccount token and deletes it at session end |
| Operational command | The controller can’t mint natively, but the credential exists in your customer’s environment and an approved command can fetch or generate it | A database: an approved operational command reads the password from your customer’s secret store, or runs CREATE ROLE ... VALID UNTIL to generate a short-lived login |
| Out of band | Break glass supplies no credential; the operator already holds one | A self-hosted service that uses a shared secret, and break glass provides only the network path |
psql or kubectl, launch a
one-shot pod, and so on. A recipe is never a Terraform template, so a
minted secret is never written into Terraform state.
“Out of band” does not mean the resource has no credential. It means
break glass isn’t the thing supplying it. The operator authenticates
with a credential they already hold or that your customer provided
directly; break glass only opens the network path.
The lifecycle
Every break glass session moves through the same shape, regardless of which planes it resolves:Request
An operator opens the Break Glass page in your vendor portal, picks one
resource, and submits a request with a reason and a requested duration.
Approve
Your customer reviews the exact request (which resource, what privilege,
how long) and signs an approval with a private key that never leaves
their environment. They can also reject.
Connect
The appliance controller verifies the signature locally, then assembles
the session: where the credential source mints one, it mints a short-lived
credential scoped to exactly what was approved; where the target is
private, it stands up a temporary, session-scoped network path. The
session goes active only when every plane it needs is ready.
Work
The operator uses the resource for the session: fetches a ready-to-use
kubeconfig and runs
kubectl, or connects to the database, and so on.
The session has an expiry set from the approved duration.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 it.
What your customer sees
When you request access, your customer is sent (via your existing notification channel) a unique web link to your support portal. The link opens an approval page showing the exact resource, the privilege being requested, the reason, and the duration. Approving means signing the request with your customer’s own key; the appliance controller running in their account verifies that signature before it mints anything. This is the same signing keypair your customer uses to approve operations commands. If they’ve already set it up for operations, break glass approvals work immediately. See Security model for the trust properties and operations security for how the keypair is generated, stored, and pinned.Where to go next
| If you want to… | Read |
|---|---|
| Walk the operator’s request-to-teardown flow in detail | Requesting access |
| Configure how break glass reaches private targets (Direct, Tailscale, Twingate) | Network providers |
| Understand the approval, least-privilege, and audit guarantees underneath | Security model |
| See how the standing, command-based channel works | How operations work |