# Operator Console

> How the Tunnel operator console gates access with the server-side operator allowlist, how the shared portal session works, and what each screen covers.

The Tunnel operator console is the web surface for the `rnp` / QUICKDesk
QUIC tunnel modality. It is an operator-facing console, not a tenant
console: `rnp` users are individuals, so there is no tenant or org
switcher in the shell. Every screen is gated by a server-side operator
allowlist, and the shell renders whatever allow/deny answer the server
returns.

The sidebar is grouped into **Start** (Overview, Get started),
**Operate** (Users & devices, Usage & billing, Webhooks) and **Ship**
(Releases).

## Who can open this console

Two conditions must both hold:

1. You have a signed-in portal session (shared across the
   ClutchCall portal subdomains).
2. The signed-in email address is on the tunnel operator allowlist that
   the control-plane API reads from `TUNNEL_ADMIN_EMAILS`.

The allowlist is enforced on the server, in the control-plane API's
`adminTunnel` router. The browser does not decide who is an operator —
it only displays the server's decision. There is no in-console screen
for editing the allowlist; it is deployment configuration.

## The platform operator badge

When the access check succeeds, the top bar renders a
`platform operator` pill next to the shield icon. That badge and the
console body are driven by the *same* single access check, so the badge
can never disagree with what the screens will let you do. If you do not
see the badge, you are not an operator on this deployment — no screen
below it will load data either.

The account menu (the circular avatar at the top right) shows the
signed-in email, labels the surface as the **Tunnel operator console**,
and offers **Portal hub** and **Sign out**.

## The operator allowlist and the two denial states

On load, the shell issues one cheap probe against
`adminTunnel.overview`. The probe's result classifies the whole shell
into one of four states:

| State | What you see | Meaning |
| ----- | ------------ | ------- |
| Checking | `Checking operator access…` | The probe is in flight, or the shared session cookie has not hydrated yet. |
| `Sign in required` | Lock icon, **Sign in** button to the portal login | The probe returned `UNAUTHORIZED`. No portal session was presented. |
| `Not a tunnel operator` | Shield icon, **Reload** button | The probe returned any other error code (the allowlist rejection, `FORBIDDEN`). You are signed in, but this address is not an operator. |
| Allowed | `platform operator` badge and the routed screen | The probe succeeded. |

### Sign in required

The probe reached the control-plane API without an authenticated
session. The panel points you at the portal hub's login route, because
sign-in happens there and not in this console.

### Not a tunnel operator

The probe carried a valid session, but the address is not on the
operator allowlist. The panel names the address it was signed in as, so
you can tell immediately whether you are on the wrong account or the
right account is simply not allowlisted. The remedy stated in the UI is
to ask an operator to add the address, then reload — which is why the
button is **Reload** rather than a sign-in link.

Because the allowlist lives server-side, adding an address takes effect
without any client-side change: reload the tab and the probe re-runs.

## Portal sign-in and the shared session

Sign-in is not performed in this console. The console:

- Waits for the SSO cookie hydration to complete **before** firing the
  access probe. Without that wait, a freshly opened tab could cache an
  `UNAUTHORIZED` result that no longer reflects the real session state.
- Sends a cold visitor to the portal to sign in before the console
  paints.
- Tracks auth state changes for the lifetime of the page, so the
  displayed email follows the session.

Sign-out is deliberately global: the account menu signs you out
everywhere the shared session applies, then redirects to the portal hub
root. Signing out of the Tunnel console therefore ends the session for
the other consoles on the same portal domain as well.

The access probe is configured not to retry and not to refetch on window
focus. An access decision is re-evaluated on a reload, not on tab focus.

## Screens: users and devices, usage and billing, webhooks, releases

All four screens live behind the operator gate.

| Screen | Route | Covers |
| ------ | ----- | ------ |
| Overview | `/` | The operator landing screen. Its data comes from the same `adminTunnel.overview` procedure that the access probe uses. |
| Get started | `/get-started` | The shared onboarding walkthrough for the tunnel modality. |
| Users & devices | `/users` | The `rnp` individuals and the devices registered to them. |
| Usage & billing | `/billing` | Tunnel usage and the billing view for it. |
| Webhooks | `/webhooks` | Webhook endpoints for tunnel events. |
| Releases | `/releases` | `rnp-cli` releases shipped to operators. |

Unknown paths redirect to Overview.

The console also ships a guided product tour and a **Docs** link in the
top bar that deep-links into this documentation set. A theme toggle
switches between dark and light.

## Relationship to the CLI and the data plane

This console is an administrative view over the same tunnel modality
that `rnp-cli` drives. It does not replace the CLI: tunnels are
established by the client, over QUIC, and the console reports on the
users, devices, usage, webhook subscriptions and CLI releases around
them. For the wire model and the data-plane behaviour, see the tunnel
modality pages; for how sessions and credentials are minted across
ClutchCall surfaces, see
[Authentication](/concepts/authentication).

## Operational notes

- Error monitoring is a no-op unless a Sentry DSN is configured for the
  deployment. When it is set, events from this console are tagged with
  `vertical='tunnel'`.
- White-labelled deployments (portal → Settings → Branding) replace the
  mark and wordmark in the sidebar. The `rnp · quic tunnel` sub-label
  stays: it identifies the surface, not the vendor.
- The nav collapses to a drawer on narrow viewports; grids reflow and
  tables scroll.

## Related

- [Authentication](/concepts/authentication)
- [Telemetry](/platform/telemetry)