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:
Both surfaces share the same trust core (a customer-signed approval the
appliance controller verifies before anything happens), so the concepts below will
feel familiar if you’ve used operations.
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.
The network path is resolved, not chosen: break glass inspects the
target’s actual reachability and decides whether a tunnel is needed. You
don’t pick “directly reachable vs. tunnel”; that follows from the
resource. See Network providers
for how each path is configured.
How the credential is minted
The credential plane is where most of the variation lives:
The operational-command path is the general mechanism and the expected
story for most resources: a credential is whatever a customer-approved
operational command produces, and it reuses the same approval machinery
as operations. A credential recipe is a
shell-script command, so it can do whatever a script can: read a secret
from your customer’s secret store, run
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:1
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.
2
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.
3
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.
4
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.5
Expire
At the end, any temporary credential and network path are removed. A
minted credential is also short-lived on its own clock, so access ends
even if teardown is interrupted. The request, the signed approval, and
teardown are recorded.
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.