> ## Documentation Index > Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt > Use this file to discover all available pages before exploring further. # How Break Glass Works Your customers run your software inside their own cloud accounts. You have no standing SSH keys, no kubectl context, no database password. The [operations](/fundamentals/operations) surface covers most of what you need (run a vetted command, get the output back), but sometimes you need to reach a specific resource directly: open an interactive `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. How break glass works in five steps: an operator requests access to one resource with a reason and time limit, your customer reviews and cryptographically signs the request, a short-lived credential is minted (and a temporary network path if the target is private), the operator works on the resource for the session, then access self-expires and is torn down with every step logged. How break glass works in five steps: an operator requests access to one resource with a reason and time limit, your customer reviews and cryptographically signs the request, a short-lived credential is minted (and a temporary network path if the target is private), the operator works on the resource for the session, then access self-expires and is torn down with every step logged. ## 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](/fundamentals/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 | 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. | 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). | 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](/fundamentals/break-glass/providers) for how each path is configured. ### 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 | 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](/fundamentals/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: 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. 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. 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. 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. 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. See [Requesting access](/fundamentals/break-glass/lifecycle) for the operator's side of this flow in detail. ## 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](/fundamentals/break-glass/security) for the trust properties and [operations security](/fundamentals/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](/fundamentals/break-glass/lifecycle) | | Configure how break glass reaches private targets (Direct, Tailscale, Twingate) | [Network providers](/fundamentals/break-glass/providers) | | Understand the approval, least-privilege, and audit guarantees underneath | [Security model](/fundamentals/break-glass/security) | | See how the standing, command-based channel works | [How operations work](/fundamentals/operations) |