tegwick
6d85f95c8b
flex-auth-tenant-engine Helm rev 2 is enforce on sha256:138aa347 after tenant-engine 2063470 started sending a projected caller token (sha256:7dc9d7bf). Probe 200/401/403. tenancy.current.A is 2. T04 cancelled: AuthZEN waits for a PEP we do not control.
3.3 KiB
ADR 0004 — authenticate and bind authorization callers
Status: accepted (both production pins enforce as of 2026-08-19)
Date: 2026-08-18
Context
POST /v1/check and /v1/batch_check accepted an asserted subject, tenant and
protected-system name from any workload with network reach. NetworkPolicy
limited reachability but did not establish caller identity. A caller could
therefore represent another protected system and obtain an authoritative
decision under the wrong policy package.
The boundary must authenticate workloads without turning flex-auth into an identity issuer, sharing a long-lived secret between services, or coupling authorization availability to an unrelated identity-provider round trip.
Decision
Use Kubernetes ServiceAccount tokens with audience flex-auth. flex-auth calls
the Kubernetes TokenReview API through a separately projected reviewer token
and binds the authenticated ServiceAccount principal to every
resource.system in the request. Both the single and batch endpoints use the
same choke point; health remains unauthenticated. The reviewer token uses the
API server's default audiences so it can authenticate to TokenReview; a
custom audience of https://kubernetes.default.svc 401s on this cluster
(https://kubernetes.default.svc.cluster.local and k3s). Caller tokens
keep audience flex-auth.
Each deployed policy instance has an explicit, exact binding. For example:
tenant-engine=system:serviceaccount:tenant-engine:tenant-engine
user-engine=system:serviceaccount:user-engine:user-engine
Unknown systems, missing or invalid tokens, audience mismatch and principal mismatch fail closed. TokenReview unavailability returns 503 rather than an authorization answer. Tokens and reviewer credentials are re-read rather than cached across rotation.
Three modes support promotion: disabled, warn, and enforce. Warn mode
records the same authentication failures without logging credentials. It is a
bounded migration aid, not a conformant steady state. The first production pin
is warn on each independently rollable Deployment; enforce is the end
state and is flipped per consumer after that consumer's warn logs are clean.
Promotion follows FLEX-WP-0011. The two production pins must not be flipped
together: user-engine can enforce while tenant-engine stays in warn.
Rejected alternatives
- NetworkPolicy alone proves network position, not workload identity.
- A shared header secret has broad replay and rotation blast radius and cannot bind a Kubernetes workload principal.
- Application mTLS would add a separate certificate lifecycle where the cluster already has short-lived projected workload identity.
- Using the caller token itself to invoke TokenReview would grant callers an
unnecessary API permission. A narrow reviewer ServiceAccount holds only
createontokenreviews.authentication.k8s.io.
Consequences
- Caller identity is bound once at the flex-auth ingress and cannot be swapped by changing request JSON.
- flex-auth depends on the Kubernetes authentication API for uncached checks; an outage fails closed with 503.
- Each new protected system needs an explicit binding and projected caller token. There is no wildcard binding.
- Source and desired state reach A2, while the live declaration remains A0 until the immutable digest is promoted and probed.