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

Close WARDEN-WP-0039 with fetch-pin receipts; activate audit-core-senders pointer

Browse source 
- WP-0039-T03: receipts against flex-auth-ops-warden-fetch with ops-warden's
  own caller token. Positive forgejo-admin-api-token allow; negatives for
  unknown need, wrong owner (403), wrong tenant and anonymous caller (401).
  Policy decisions only, no credential read. WP-0039 finished.
- audit-core-senders: active as a pointer on ops-mason's custody check
  (message 5a516911). Custody text corrected to OpenBao KV v2 read via ESO;
  delegation verified source-read.
- WP-0044: oidc-browser-relying-party 1.1 is plannable; the case-ref is taken
  at run time because it covers the case status.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 427672@bnt-lap001
Assistant-Session: a0a2367e-4697-440c-a4e5-9713c009f6d8
This commit is contained in:
tegwick 2026-10-10 15:26:38 +02:00
parent 9fd65ec4b5
commit b76ee0edae
5 changed files with 52 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files

20
registry/routing/catalog.yaml
View file

@ -1320,6 +1320,16 @@ entries:
- id: audit-core-senders
title: audit-core sender registry (write and operator-read tokens)
# Vends write and operator-read tokens (WARDEN-WP-0032-T05).
# Activated 2026-10-10 as a pointer on ops-mason's custody check (message
# 5a516911, ops-mason-survey grant, metadata and policy text only):
# - KV v2 at platform/workloads/audit-core/senders, v11, with all five
# custody fields present.
# - Only external-secrets-audit-core grants a data read.
# - agent-high-risk-boundary denies the data path, and the tenant-engine
# projection policy does not name it.
# ESO reads it by token auth; the parent token renewal is due 2026-10-25,
# under railiance-platform RPF-WP-0046. A live-token capability check is
# owner-run and not yet done.
risk: high
workload_ref:
applicability: applicable
@ -1330,20 +1340,20 @@ entries:
warden_executes: false
wiki_ref: wiki/playbooks/audit-core-senders.md#worker-checklist
canon_ref: audit-core/docs/operator-runbook.md
reviewed: "2026-08-13"
status: draft
reviewed: "2026-10-10"
status: active
delegation:
mode: native
intended_owner: ops-mason
reviewed: "2026-10-09"
verified: unverified
reviewed: "2026-10-10"
verified: source-read
# Per-sender projections. Each is verified on its own and none activates the
# registry lane. tenant-engine: KV platform/workloads/tenant-engine/audit-core-sender
# (v1), read policy workload-kv-read-tenant-engine-audit-core-sender-eso (exact
# read, no registry path), ESO-delivered; verified by ops-mason 2026-10-09
# (MASON-WP-0007-T06, message e7e866bf).
consumers: [tenant-engine]
auth_method: "in-cluster generated Secret audit-core-senders; later OpenBao KV via Mason wrap-migrate"
auth_method: "OpenBao KV v2 custody; audit-core reads via ESO (policy external-secrets-audit-core, token auth). Operators and agents never read the registry; a sender gets its own exact-path projection."
path_template: "platform/workloads/audit-core/senders"
policy_ref: "external-secrets-audit-core"
exec_capable: false

1
wiki/CredentialRouting.md
View file

@ -108,6 +108,7 @@ lists the interim set — WARDEN-WP-0030).
| `net-kingdom-lldap-bind-credential` | "railiance-platform custody for the LLDAP bind credential used by identity-provisioner and the privacyIDEA resolver" | Follow the owner-approved NetKingdom reconciliation runbook; lane is currently unresolved and never fetches a value |
| `net-kingdom-privacyidea-admin-token` | "railiance-platform custody for the privacyIDEA administrative token used by attended resolver reconciliation" | Follow the owner-approved NetKingdom reconciliation runbook; lane is currently unresolved and never fetches a value |
| `keycape-client-secret-generate` | "railiance-platform's broker generates a KeyCape client secret inside custody for an accepted SecurityCase. The value is never returned" | `bao login` to role `credential-broker-keycape-client-secret-generate`, then `credential.py generate --case-file ... --case-ref ...` (see playbook). Agents are refused |
| `audit-core-senders` | "ops-mason built the audit-core sender registry in OpenBao. audit-core reads it through ESO only" | Nobody reads the registry. A sender gets its own exact-path projection (see playbook table) |
Promotion criteria: `wiki/playbooks/catalog-lane-promotion.md`.
High-risk / agent boundary: `wiki/playbooks/agent-read-boundary.md`.

9
wiki/playbooks/audit-core-senders.md
View file

@ -10,10 +10,11 @@ does not duplicate the operating procedure.
- Database leases (separate lane): `warden route show database-dynamic-credentials`
- Authoritative senders shape: `audit-core/docs/senders.example.json` (placeholders only)
First deploy mints sender tokens in-cluster into Secret
`audit-core/audit-core-senders`. The OpenBao path
`platform/workloads/audit-core/senders` is the later authority, filled by a
Mason wrap-migrate — not by a founder `bao kv put`.
The registry lives in OpenBao KV v2 at `platform/workloads/audit-core/senders`.
It was filled by a Mason wrap-migrate, never by a founder `bao kv put`.
audit-core reads it only through ESO (policy `external-secrets-audit-core`).
`agent-high-risk-boundary` denies agents the data path. Checked by ops-mason on
2026-10-10, from metadata and policy text only.
## Sender projections

27
workplans/WARDEN-WP-0039-explicit-policy-refusal.md
View file

@ -4,7 +4,7 @@ type: workplan
title: "Preserve explicit policy caller refusals before credential and CA effects"
domain: infotech
repo: ops-warden
status: blocked
status: finished
flavor: residual
owner: codex
topic_slug: custodian
@ -60,12 +60,10 @@ Verify the installed module as well as the checkout before the live refusal test
```task
id: WARDEN-WP-0039-T03
status: wait
status: done
flavor: residual
priority: high
assignee: the-custodian
needs_human: true
blocking_reason: "Code side done 2026-10-03 (policy.fetch_flex_auth_url). Waits on founder go: deploy access-engine pin flex-auth-ops-warden-fetch, add tunnel flex-auth-ops-warden-fetch-railiance01, set the key in live warden.yaml, then record positive and wrong-owner evidence."
state_hub_task_id: "8ca28b63-2e04-5333-b635-011b124c1806"
```
@ -138,3 +136,24 @@ ClusterIP:8080), set `fetch_flex_auth_url: http://127.0.0.1:19091` in the live
wrong-owner/caller negative evidence before T03 closes. Until the key is set,
every proxied fetch refuses with "secret-read evaluator not configured". Before
that change, those fetches got a 403 from the signing pin.
**T03 done 2026-10-10.** access-engine reported the fetch pin
`flex-auth-ops-warden-fetch` live since 2026-10-03 (Helm revision 1). The tunnel
`flex-auth-ops-warden-fetch-railiance01` (127.0.0.1:19091) is connected, and the
live `~/.config/warden/warden.yaml` carries
`fetch_flex_auth_url: http://127.0.0.1:19091`. Receipts were taken with
ops-warden's own caller token (SA `ops-warden/ops-warden`, audience
`flex-auth`, 10m). The requests are access-engine's fixtures in
`examples/ops-warden-fetch/`. Policy decisions only; no credential was read.
| Case | Result |
| --- | --- |
| Positive: `forgejo-admin-api-token`, owner railiance-platform | HTTP 200 allow `secret_read_lane_matched`, `decision:014afa428f776db5` |
| Unknown need | HTTP 200 deny `unknown_need`, `decision:d792b0d6b1cb8122` |
| Wrong owner: `resource.system` ops-warden | HTTP 403 |
| Wrong tenant: `tenant:binky` on subject and resource | HTTP 200 deny `wrong_tenant`, `decision:71da3ff8b50dad74` |
| Wrong caller: anonymous | HTTP 401 |
This is the exact positive evidence plus the caller, owner and tenant negatives
this task required. The explicit refusal stays for anything the pin does not
admit. access-engine closes its ADHOC-2026-10-03-T02 on this reply.

8
workplans/WARDEN-WP-0044-security-case-follow-through.md
View file

@ -194,6 +194,14 @@ go-ahead (message 20973a9c) after key-cape confirmed the format (4e0213b3).
only thing T03 still waits on is the Forgejo case reaching `materialized`
(MASON-WP-0010-T03).
2026-10-10: net-kingdom moved the type to 1.1 (`e2174ce`) and re-pinned the
Forgejo case. 1.1 adds the verification `consumer-enforces-groups` and requires
the hand-over to enforce `access_groups`. `check-type` on 1.1 reports
`plannable=True`, and a materialized copy renders six steps and the new check.
The case-ref digest covers the whole case file, including `status`, so it
changes when the case becomes `materialized`. `warden case run` therefore takes
it from the file at run time, and the broker re-derives it from the same file.
```task
id: WARDEN-WP-0044-T04
status: wait