Requests and approvals are handled in the console at app.subnomic.com.
Two ways access gets gated
- Connect-time (servers, apps, clusters) — an admin turns on Require approval to connect on the target. Opening its terminal / app / API then needs an active grant.
- Per-statement (databases) — a
require_approvalguardrail gates specific queries (see Guardrails), while still allowing the rest.
Turning it on (admin)
- Server — open the server → Overview → Access card → toggle "Require approval to connect".
- Internal app / Cluster — tick "Require approval to connect" in the New app / New cluster form.
- Database — add a
require_approvalguardrail for the query (or target) you want gated.
Requesting access
- Hit a gated target — the console / terminal shows Request access.
- Click it (or go to Access requests). Your request appears under "My requests" as pending.
- Once approved, just retry — reconnect the terminal, reopen the app, or re-run the query. It passes for the duration of the grant.
Reviewing (approvers)
- Approvers are notified and see requests under Access requests → Pending review.
- Each row shows the requester, the target (type badge + name) and the reason — so you know exactly what you are granting.
- Approve (set a duration in minutes) or Deny.
- The Active grants section lists every standing grant; Revoke ends one immediately.
For kubectl, the grant binds to the user who downloaded the kubeconfig (its embedded API
key), so the gate applies to the local CLI too — not just the browser console.
Permissions
access.request
access.review
No grant is a bypass of RBAC — a user still needs the base permission to connect (e.g. terminal access); the grant only lifts the approval gate. See Break-glass for the emergency path.