> ## 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. # Requesting Access A break glass session moves through a state machine on its way from "I need to get into this resource" to "the session is over and everything is torn down." This page walks your side of that flow: how to request access, what your customer sees in parallel, how the session is assembled, and how it ends. ## Requesting access You start a request from the **Break Glass** page in your vendor portal. Pick the appliance and the one resource you need to reach, then submit: | You specify | Notes | | --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Resource** | The single resource the session targets (a cluster, a database, a service). One session reaches one resource. | | **Reason** | Free-text justification. Shown to your customer at approval time and recorded in the audit trail. | | **Duration** | How long you need. This bounds the session and the lifetime of any credential minted for it, measured from when the session becomes active. | | **Credential source** | How the credential is produced for this resource: minted by the appliance controller, minted by an approved operational command, or supplied out of band. Offered only where more than one applies. | You do not pick the network path. Break glass resolves that from the resource: if the target is already reachable it uses the Direct path; if it's private it stands up a temporary tunnel through your configured provider. See [Network providers](/fundamentals/break-glass/providers). Once submitted, the request is **Pending** and your customer's review begins. 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 the duration. ## Session states The happy path is request, approve, assemble, use, expire. A few terminal states cover the ways a session can stop early. | State | What it means | | -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Pending** | The request exists and is waiting on your customer's decision. You can withdraw it; it also auto-expires if your customer never acts within the request window. | | **Activating** | Your customer approved. Break glass is assembling the session: minting the credential where break glass supplies one, and (for a private target) bringing the temporary network path online. | | **Active** | Every plane the session needs is ready. You can use the resource. The session carries an expiry derived from the approved duration. | | **Ended** | The session finished. The temporary credential and any temporary network path have been removed. | Terminal states for a session that stopped early: | State | What happened | | ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Rejected** | Your customer declined the request at review. A rejection can carry a reason back to you. | | **Cancelled** | You withdrew the request before your customer acted. | | **Failed** | The session couldn't be fully assembled or torn down (for example, a temporary tunnel never came online). Break glass fails closed: a session that can't be assembled does not go active. | A session goes **Active** only when every plane it needs is ready. For a private target with a minted credential that means the credential is minted *and* the tunnel is online; if either half can't complete, the session does not activate. An out-of-band session resolves only the network path (the operator brings their own credential), so it activates once that path is online. ## What your customer sees When you submit a request, your customer is sent (via your existing notification channel) a unique support-portal link. Opening it shows the exact request: which resource, the privilege being requested, your reason, and the duration. Your customer picks Approve or Reject. Approving means **signing** the request. Your customer signs with a private key that lives in their own environment and never travels to your control plane; the appliance controller running in their account verifies that signature against a public key only your customer controls before it mints anything. This is the same signing keypair your customer uses to approve [operations](/fundamentals/operations) commands, so if they've used operations, break glass approvals work immediately. See [operations security](/fundamentals/operations/security) for how the keypair is generated, stored, and pinned. The approval is bound to this one request. It cannot be redirected at a different resource, widened in privilege, or extended in duration after your customer signs; any such change breaks the signature. Approvals also have a short validity window and are single-use, so a captured approval can't be replayed later. ## Using the session Once the session is **Active**, break glass delivers what the operator needs to connect: * **Kubernetes**: a ready-to-use kubeconfig for the session. It carries the minted, short-lived credential and the cluster endpoint; point `kubectl` at it and work normally. * **Database and other resources**: the connection details produced by the approved credential source (for example, a short-lived database login). * **Out-of-band sessions**: break glass delivers the network path so the otherwise-private endpoint becomes reachable, and the operator authenticates with the credential they already hold. Break glass delivers no credential in this case. A minted credential is delivered to the operator once (consumed on read) and is not durably stored by the control plane. Treat the delivered connection details as the session's secret: they're scoped to this one session and expire with it. A minted credential's lifetime can be capped below the approved duration by your customer's own environment (for example, a Kubernetes cluster's maximum service-account token lifetime). If that cap is shorter than your session, the credential can expire mid-session and is not re-minted automatically; request a fresh session if you need more time. ## Expiry, teardown, and revocation Access ends when the session ends, and it ends two ways, both bounded: * **Self-expiry.** A minted credential is short-lived, with a lifetime tied to the approved duration. Even if teardown is interrupted, the credential stops working on its own clock. * **Explicit teardown.** At session end, break glass removes what it created: it deletes any minted identity (revoking the credential) and tears down any temporary network path. For an out-of-band session there is no minted credential to revoke, so only the network path is removed. Confirmed teardown is recorded. To end a session early, end it from the Break Glass page; teardown runs immediately rather than waiting for the expiry. Because the credential also self-expires, ending early and letting it lapse both converge on the same result: no standing access remains. ## Related * [How break glass works](/fundamentals/break-glass): the two-plane model and where this flow fits. * [Network providers](/fundamentals/break-glass/providers): how the network path for a private target is configured. * [Security model](/fundamentals/break-glass/security): the approval, least-privilege, and audit guarantees behind this lifecycle.