coulomb/ops-warden
5
0
Fork 0
Code Issues Pull requests Projects Releases 2 Packages Wiki Activity Actions

Show the OpenBao identity warden access evaluates

Browse source 
reuse-surface-hub-write-token does not select a caller. The data plane
uses the ambient token, which can be the coding-agent role denied by
agent-high-risk-boundary while an attended platform-admin lookup still
shows read. Advisory and proxy output now report that entity, role, and
policies without the token. CCR-2026-0005 still has no OIDC binding for
workload-kv-read-reuse-surface-runtime.

Assistant: grok
Assistant-Session: 01a13b2d-0bc1-7a91-ab1d-325bcfb09bf0
This commit is contained in:
tegwick 2026-10-14 18:21:02 +02:00
parent 6e1430073c
commit 8dbf62515a
6 changed files with 367 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

15
wiki/playbooks/reuse-surface-hub-write-token.md
View file

@ -28,6 +28,21 @@ ops-warden does not vend this token — custody belongs to `railiance-platform`
`SecretSynced`, positive hub + webhook verification and negative default-policy denial
recorded in CCR-2026-0005.
### Which identity this route evaluates
`warden access` does not pick a principal. Two identities are involved, and they are not the same:
| Plane | Identity |
| --- | --- |
| OpenBao data read | The ambient token: `BAO_TOKEN`, else `VAULT_TOKEN`, else `~/.vault-token`. `warden access` prints the entity, OIDC role, and policies before a proxy. |
| flex-auth gate | `policy.caller_auth` in `warden.yaml`. On this workstation that mints a short-lived token for ServiceAccount `ops-warden/ops-warden`. An allow here does not mean OpenBao allowed the read. |
A capabilities check on one shell and a proxy in another can disagree. The OpenBao CLI in the proxy uses that process's ambient token. An attended `platform-admin` login (entity `4a1f663c-0621-0483-edd0-f852274f4b6b`, policies `default`, `operator-custody`, `platform-admin`) can show `read` on both exact paths while `auth/netkingdom/role/coding-agent` is denied: that role's `agent-high-risk-boundary` policy denies data read on this path. The 2026-10-14 hub registration attempt was that shape. PDP decision `f730e3da14beebdd` allowed the fetch; OpenBao then returned HTTP 403 and the helper did not run.
Do not attach `workload-kv-read-reuse-surface-runtime` to the platform-admin entity. CCR-2026-0005 does not name that caller. The only live binding is Kubernetes role `auth/kubernetes/role/reuse-surface-runtime-eso` (ServiceAccount `reuse/reuse-surface-eso`, audience `openbao`) with policy `workload-kv-read-reuse-surface-runtime-eso`: data read plus token self lookup and revoke. The caller-facing policy file allows read of the exact data and metadata paths and is not attached to any `auth/netkingdom` role.
A dedicated caller is a new `auth/netkingdom` OIDC role in railiance-platform, same shape as the other `workload-kv-read` roles: `token_policies` only `workload-kv-read-reuse-surface-runtime`, `token_no_default_policy` true, and a sibling path still denied. Platform-operator and reuse-surface-owner approve the named principal first. ops-warden does not apply that binding.
### Break-glass (cluster read)
If OpenBao is unreachable, operators with Railiance01 kubeconfig may read the