Skip to main content
Autopilot’s dashboard ships open on an internal cluster and locked down when you need it to be — both behind one feature gate, auth.enabled (default false). Turning it on adds sign-in, role- and namespace-scoped authorization, an access-request queue, and an audited login trail, with a single enforcement point in the server.
With auth.enabled=false, the dashboard behaves exactly as it always has — any reachable client has full access. Authentication and every control below are inert until you enable it. This page covers the enabled state.

​
Signing in

Two methods, one active per cluster:
  • Xano (default) — validates against a Xano instance.
  • Google OAuth/OIDC — with hosted-domain enforcement. See the Google OAuth setup runbook.
Either way, a user is resolved to a role by email against the cluster’s AccessPolicy CRD.

​
Roles and scope

Authorization is an AccessPolicy (a cluster singleton) plus per-user grants:
  • Roles — viewer (read), admin (mutate + privileged tools). Read endpoints require viewer+; every mutation and every pod tool re-checks admin in-handler.
  • Namespace scope — a grant can be limited to specific namespaces (glob patterns supported). A scoped user only ever sees and acts on their granted namespaces; an out-of-scope request returns an authorization error with no data. An empty scope means full access.
  • Super-admins — a bootstrap list (AUTH_SUPER_ADMINS) that resolves to admin even with no AccessPolicy present. Unkillable via the API — your lockout insurance.
  • Domain allowlist + deny list — a whole domain can be granted a default (suggested) role, and specific emails denied.

​
Self-service access requests

A first-time authenticated user with no grant lands on an access-request screen instead of a dead end. The request is deduplicated, rate-limited, and (optionally) sent to Slack. An admin approves or denies it on the Access Control → Pending Requests page — approval writes the grant, denial optionally adds the email to the deny list. Every decision is audited.

​
Audit trail

Every login, access request, approval/denial, and privileged action (including every pod tool open) writes a typed event to a shared audit ring, surfaced on the Auth Events page (GET /api/v1/access-events) and durably to Cloud Logging. Filter chips separate login events from terminal/logs/files events.

​
API keys (for the MCP server)

For non-interactive clients, an admin can mint a long-lived, revocable, read-only API key. A key resolves only to an email — the role and namespace scope are read live from that email’s grant on every request, so revoking or re-scoping the grant instantly re-scopes the key. Only a hash is stored; the plaintext is shown once. See the MCP server reference for how a client uses it.

​
Enabling it

Public exposure adds a safety interlock: when the dashboard is exposed via an ingress and auth is off, the /mcp endpoint and the API-key management endpoints fail closed (503) — a public, unauthenticated cluster can never serve those.