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

Name the verified reuse-surface hub-writer login

Browse source 
CCR-2026-0044 is applied. Member and non-member receipts passed on
2026-10-14: the member token holds only
workload-kv-read-reuse-surface-runtime, and a non-member login is
refused. The catalog auth_method is now that OIDC role. The proxy still
uses the ambient token and does not vend the hub writer value.

Assistant: grok
Assistant-Session: 01a13b2d-0bc1-7a91-ab1d-325bcfb09bf0
This commit is contained in:
tegwick 2026-10-14 22:20:15 +02:00
parent 638cc9233b
commit 402b008986
3 changed files with 21 additions and 17 deletions
Download patch file Download diff file Expand all files Collapse all files

15
registry/routing/catalog.yaml
View file

@ -663,15 +663,12 @@ entries:
# reuse/reuse-surface-runtime SecretSynced to reuse-surface-env on Railiance01;
# positive + negative access verified. Production consumer is ESO; warden access
# proxies reads as the caller and never holds the value.
# Data-plane identity is whichever token the OpenBao CLI resolves
# (BAO_TOKEN, then VAULT_TOKEN, then ~/.vault-token). That is not the
# flex-auth caller. CCR-2026-0005 does not bind an OIDC role. The only
# live binding is Kubernetes role reuse-surface-runtime-eso.
# CCR-2026-0044 (proposed, railiance-platform) reserves a dedicated
# caller. ops-mason (MASON-WP-0011) says that role stays out of
# auth_method until member and non-member verification both pass.
# platform-admin must not receive the scoped policy. See the playbook.
auth_method: "ambient OpenBao token (BAO_TOKEN, then VAULT_TOKEN, then ~/.vault-token); dedicated caller unnamed until CCR-2026-0044 is approved and member plus non-member verification pass"
# Dedicated caller: CCR-2026-0044 applied. Group reuse-surface-hub-writers,
# assurance aal2, policy workload-kv-read-reuse-surface-runtime only.
# Member and non-member receipts passed 2026-10-14 (ops-mason). The proxy
# still uses the ambient token after this login. platform-admin must not
# receive the scoped policy. ESO stays on reuse-surface-runtime-eso.
auth_method: "bao login -method=oidc -path=netkingdom role=reuse-surface-hub-writer-workload-kv-read"
path_template: "platform/workloads/reuse/reuse-surface/runtime-secrets"
fetch_command: "bao kv get -field=REUSE_SURFACE_TOKEN platform/workloads/reuse/reuse-surface/runtime-secrets"
policy_ref: "flex-auth check secret.read:reuse"

11
tests/test_reuse_surface_caller_gate.py
View file

@ -6,12 +6,11 @@ from pathlib import Path
from warden.routing import load_catalog
def test_dedicated_caller_stays_unnamed_until_ccr_2026_0044_verification():
def test_dedicated_caller_is_the_verified_hub_writer_role():
catalog = load_catalog(Path(__file__).resolve().parents[1] / "registry" / "routing" / "catalog.yaml")
entry = catalog.get("reuse-surface-hub-write-token")
assert entry is not None
auth = entry.auth_method or ""
# MASON-WP-0011: the proposed OIDC role is not the auth method yet.
assert "reuse-surface-hub-writer" not in auth
assert "CCR-2026-0044" in auth
assert "unnamed" in auth
assert entry.auth_method == (
"bao login -method=oidc -path=netkingdom "
"role=reuse-surface-hub-writer-workload-kv-read"
)

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

@ -39,9 +39,17 @@ recorded in CCR-2026-0005.
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 live `auth/netkingdom` role.
Do not attach `workload-kv-read-reuse-surface-runtime` to the platform-admin entity `4a1f663c-0621-0483-edd0-f852274f4b6b`. CCR-2026-0005 remains the KV and ESO authority. ESO still uses Kubernetes role `auth/kubernetes/role/reuse-surface-runtime-eso` with policy `workload-kv-read-reuse-surface-runtime-eso`.
The dedicated caller is proposed, not applied. railiance-platform `CCR-2026-0044` (status `proposed`) and ops-mason `MASON-WP-0011` reserve OIDC role `reuse-surface-hub-writer-workload-kv-read` for group `reuse-surface-hub-writers`, policy `workload-kv-read-reuse-surface-runtime` only. Apply waits on platform-operator and reuse-surface-owner approval, key-cape confirmation of that group, and a member entity other than `4a1f663c-0621-0483-edd0-f852274f4b6b`. The catalog `auth_method` stays unnamed until `ops-mason/scripts/verify-reuse-surface-hub-writer.py` passes in both `member` and `non-member` modes. Those receipts do not exist yet. ops-warden does not apply the role and does not put it in `auth_method` before that gate.
The attended caller is OIDC role `reuse-surface-hub-writer-workload-kv-read` on `auth/netkingdom`, group `reuse-surface-hub-writers`, assurance `aal2`, policy `workload-kv-read-reuse-surface-runtime` only. railiance-platform `CCR-2026-0044` is applied. Log in with:
```bash
bao login -method=oidc -path=netkingdom role=reuse-surface-hub-writer-workload-kv-read
```
`warden access` does not perform that login. It reads the ambient token. Use this role's token for the proxy.
ops-mason verified both modes on 2026-10-14. The member receipt (`docs/evidence/2026-10-14-reuse-surface-hub-writer-member.txt`) logged in as entity `c204099b-cb94-363f-e207-5ff4d4aa6e94` with only `workload-kv-read-reuse-surface-runtime`: read on the exact data and metadata paths, deny on the parent and on `issue-core-runtime`, then revoked. The non-member receipt refused the login. The CCR approval comment names member entity `f94b7c34-e151-30bb-b473-df3ccdbb9bf1`; the passing receipt's entity is the one above.
### Break-glass (cluster read)