WARDEN-WP-0031 T04: prove ops-warden's caller identity against the live pin
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s

flex-auth's binding names system:serviceaccount:ops-warden:ops-warden, and that
ServiceAccount did not exist. deploy/kubernetes/caller-identity.yaml creates it
plus its namespace — no RBAC, automount off; it is never used to call the
Kubernetes API, only to be TokenReviewed. Applied to the railiance01 cluster.

Operator warden.yaml now uses caller_auth mode: command (kubectl create token,
audience flex-auth, 10m). Gate exits 0 live against a port-forward of the pin:
HTTP 200, effect=allow, decision:f3f7c88f9585582a.

The evidence is not that allow — warn allows anonymous callers too. It is that
the pin's "caller authentication warning" count held at 4 across two
authenticated runs. That is the ADHOC-2026-08-17-T01 condition.

Also gives the readiness probe a structurally complete context, so a deny means
the policy said no rather than the probe being malformed.

policy.enabled stays false. T05 waits on flex-auth setting callerAuth.mode:
enforce (their FLEX-WP-0016 T03).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-08-19 19:06:04 +02:00
parent 9b9bfe565a
commit 654c05dece
5 changed files with 166 additions and 3 deletions

View file

@ -14,6 +14,7 @@ related_workplans:
- WARDEN-WP-0009
created: "2026-08-19"
updated: "2026-08-19"
state_hub_workstream_id: "7284a398-d529-4fe3-871e-e2505064be5e"
---
# WARDEN-WP-0031 — Calling-side identity for flex-auth
@ -63,6 +64,7 @@ point argument, applied to ops-warden as a caller).
id: WARDEN-WP-0031-T01
status: done
priority: high
state_hub_task_id: "cd65c834-214a-4bbb-92e4-262f124fc79d"
```
**Caller identity on the outbound policy call.** `policy.caller_auth` in
@ -80,6 +82,7 @@ until an operator opts in. Tests in `tests/test_policy.py`.
id: WARDEN-WP-0031-T02
status: done
priority: high
state_hub_task_id: "9abdeb78-bbbb-4ff5-b3d7-5646116cf68b"
```
**Readiness gate.** `scripts/check_policy_caller_identity.py` — read-only:
@ -96,6 +99,7 @@ Done 2026-08-19.
id: WARDEN-WP-0031-T03
status: done
priority: medium
state_hub_task_id: "d3ff2ae1-2dac-45d0-b229-8b23c27c3972"
```
**Docs.** `examples/warden.production.example.yaml` gains the `caller_auth`
@ -108,8 +112,9 @@ Done 2026-08-19.
```task
id: WARDEN-WP-0031-T04
status: wait
status: done
priority: high
state_hub_task_id: "3d9d1a05-adea-4dcb-b71b-bfb2235aa198"
```
**Pick the token source and prove it against the warn pin.** Operator work on
@ -120,10 +125,22 @@ against a port-forward. Expect `effect=allow` for `agt-state-hub-bridge` while
the warn log stops printing `caller authentication warning` — the absence of
that line, not the allow, is the evidence.
Done 2026-08-19. Source is `mode: command` — `kubectl create token ops-warden
-n ops-warden --audience flex-auth --duration 10m` against the railiance01
cluster (tunnel `k3s-api-railiance01`, local `16444`; note `16443` is claimed by
two tunnels at once, which is why a `system:masters` cert 401s there).
`deploy/kubernetes/caller-identity.yaml` creates the Namespace and
ServiceAccount the binding names — no RBAC, `automountServiceAccountToken:
false`; it exists only to be TokenReviewed. Gate exits 0 live:
`HTTP 200, effect=allow, decision:f3f7c88f9585582a`, and the pin's
`caller authentication warning` count held at 4 across two authenticated runs.
Evidence: `history/2026-08-19-flex-auth-caller-identity-evidence.md`.
```task
id: WARDEN-WP-0031-T05
status: wait
priority: high
state_hub_task_id: "8b8e68c4-587d-490d-a98f-840aaff0fdb8"
```
**Sequence the flip.** Only after T04: tell flex-auth to set
@ -131,3 +148,7 @@ priority: high
re-run the gate against the enforcing pin, and only then set
`policy.enabled: true` with `fail_closed: true`. Flipping before enforce buys
nothing; flipping before T04 401s every `warden sign`.
Asked flex-auth 2026-08-19 with the T04 evidence. Waiting on their enforce.
The closing `warden sign` also needs a scoped `VAULT_TOKEN` via
`ops-warden-warden-sign-token` (operator authenticates to OpenBao).