0058. OIDC login and Kubernetes impersonation for ichor-ui

Status: Accepted · Date: 2026-10-26 · Design section: Trust; CLI and UI Decided: with ichorUI.oidc.enabled (default off) every ichor-ui RPC needs an OIDC ID token that github.com/coreos/go-oidc/v3 verifies (signature, issuer, audience = client ID, expiry), the backend calls the Kubernetes API as that user with Impersonate-User/Impersonate-Group so the API server alone decides what they may do, and AuditRecord.actor and the PR's Requested by: are that Kubernetes user name; the UI is a public client doing authorization code + PKCE in the browser (no client secret exists); the impersonate grant is on users and groups only, rendered only when OIDC is on and narrowable by name; with OIDC off nothing changes except a startup warning and a UI banner; the CLI does not forward credentials

Context

architecture.md "Trust" says the UI backend holds a read-only Talos identity and the browser holds nothing, and that "OIDC login with Kubernetes impersonation comes later so that RBAC and audit apply per user". The design decides nothing more: not the flow, the library, the impersonation scope, the off-state, or the CLI. Until now AuditRecord.actor was the fixed string ichor-ui/ichor-cli, and anyone who could reach ichor-ui wrote with its ServiceAccount's permissions (ADR 0030's port-forward is the boundary).

Decisions

1. Design gives: OIDC login, Kubernetes impersonation, RBAC and audit per user, browser holds no kube/Talos credential. Everything below is what the design left open.

2. Impersonation. uiapi.Server shadows Get/List/Create/Update/Delete so a call made under a context that carries an Identity goes through a client with Impersonate-User and one Impersonate-Group per group; no handler changed. Kubernetes then enforces RBAC, and the API server's own audit log names the user. Ichor writes no authorization logic. Reads that are the backend's own business and whose result is not returned to the user (secrets bundle, argocd-cm, the repository token, the Application that planWrite inspects) stay on the ServiceAccount via s.Client: users are not meant to read the secrets bundle. A read whose result reaches the user (the tracking Application's status, the Kubernetes Node's status, TalosStorage) is made as the user; ADR 0062's amendment lists every s.Client read and which side it is on. Without an identity (point 4) the ServiceAccount is used for all of them. The Talos read-only identity is unchanged; RPCs that reach a node first read the TalosMachine as the user, so a user who cannot get it cannot reach its node data.

Scope of impersonate. One rule: verb impersonate on users and groups in the core group, cluster scoped (impersonation is a cluster-scoped verb). Not serviceaccounts, not userextras, not uids. It is rendered only when ichorUI.oidc.enabled, so the default install gains nothing. Names cannot be enumerated for a real IdP, so by default it allows any name; ichorUI.oidc.impersonate.users/.groups turn into resourceNames for sites that can list them (a user or group outside the list gets a 403). Compensating controls in the backend: names get a configurable prefix (default oidc:) so an IdP value cannot be a built-in, and a name that still starts with system: is refused. The ServiceAccount token remains the thing to protect; this grant is the reason it matters more once OIDC is on.

3. Token verification. github.com/coreos/go-oidc/v3 v3.21.0 is added. go mod graph showed only coreos/go-oidc v2.5.0+incompatible (an old indirect dep of k8s.io/apiserver, unusable for a v3 import path) and no JWKS-verifying code we could reuse without pulling in the apiserver authenticator machinery. It brings go-jose/v4, already in the module graph. The verifier does discovery, JWKS rotation, and checks signature, issuer, audience and expiry; we add: username claim present (default email, which must be email_verified), groups claim optional. Errors say "invalid ID token" and never include the token or library detail. Discovery failing at startup is fatal, never a silent fall back to open.

4. OIDC not configured. Behaviour is exactly as before: writes use the ServiceAccount, the actor is ichor-ui. It is not made stricter, so nobody is locked out on upgrade. What changes is that it is no longer silent: ichor-ui logs a WARNING at start and GET /auth/config reports enabled:false, which the UI shows as a banner. /auth/config (issuer and client ID only), the SPA assets and /metrics are open; every Connect RPC needs a token when OIDC is on.

5. CLI. The CLI runs on the user's kubeconfig (ADR 0049) and does not forward its credentials to ichor-ui: sending a kubeconfig token to a server that then acts with it is a credential-forwarding path we do not want, it would need tokenreviews to verify, and a client-certificate kubeconfig has no token to send. With OIDC on the CLI therefore uses its in-process fallback (the same uiapi.Server on the user's own RBAC; actor stays ichor-cli for now). Known consequence, not done in this change: the CLI does not yet detect an OIDC-enabled backend, so its calls through the port-forward get Unauthenticated instead of falling back; ichor ... --local works, and commands that need the backend (node) will need an ID token flag later. A follow-up should make the CLI read /auth/config, fall back automatically, and take its actor name from a SelfSubjectReview.

5a. Amendment: the CLI detects OIDC (point 5's follow-up, done). Right after the port-forward is up and the probe answers, the CLI reads GET /auth/config. enabled:true makes it drop the tunnel and use the in-process uiapi.Server on the user's own kubeconfig and RBAC, printing one line to stderr saying so. Any other answer (non-200, unparseable body, an older backend) counts as not enabled, so the call goes to the backend, which rejects it itself if it does require a token: detection never opens anything up. node get / node logs need the backend's read-only Talos identity, so with OIDC on they fail with a reason (the backend requires OIDC, the CLI cannot present a token and never forwards kubeconfig credentials) instead of Unauthenticated; the flag that would carry an ID token is still later. The in-process actor (AuditRecord.actor, Requested by:, the approval decision) is the username from a SelfSubjectReview made with the user's kubeconfig; if that call fails the actor stays ichor-cli. Only the username is read; no credential is logged or stored.

6. Login in the UI. Authorization code + PKCE (S256), state and nonce, in the browser, as a public client: there is no client secret to store, mount or leak, and the backend stays stateless (no sessions or cookies; it verifies the bearer ID token on each call). The ID token lives in sessionStorage and is sent as Authorization: Bearer; a rejected token restarts login. It is a credential for Ichor only, not for Kubernetes or Talos. Cost: the IdP must allow CORS for browser discovery and token requests and have the UI's origin as a redirect URI, and there is no refresh token, so the user logs in again when the ID token expires. A backend-held session was rejected as more code (cookie signing, CSRF, secret handling) for the same result.

7. Audit. AuditRecord.actor is Identity.User, the exact string given to Impersonate-User, so it matches Kubernetes' audit log; prmode.SubmitPRRequest.Requester receives the same value for Requested by:.

8. Secrets. The ID token and (nonexistent) client secret are never logged, put in errors or written to audit; tests assert the verifier's errors do not echo the token. Nothing logs a request header.

Amendment: what an impersonated user needs for the effective config

GetEffectiveConfig lists TalosConfigPatch and TalosStorage as the user (ADR 0062), so a user needs get/list on talosclusters, talosmachines, talosconfigpatches and talosstorages in the cluster's namespace; the chart's per-CRD *-viewer-role ClusterRoles grant exactly that. Without talosstorages list the view fails with Forbidden for that user. The ServiceAccount's own list on talosstorages (ADR 0018 amendment) is separate: it serves ResolveSystemInputs and the OIDC-off case.

Amendment: Ichor's own users and issuer (ADR 0094, Proposed)

ADR 0094 adds IchorUser accounts and makes ichor-ui an OIDC issuer of its own that runs beside the external IdP described here. Nothing in this ADR changes while ichorUI.users.enabled stays false. When it is on, the authenticator accepts tokens from both sources, the kube-apiserver trusts both through Talos's KubeAuthenticationConfig, and the CLI can present an Ichor-issued token to the backend (point 5a's "later").