From b76ee0edaefad4f697b3dae2713073f1705eba0b Mon Sep 17 00:00:00 2001 From: tegwick Date: Sat, 10 Oct 2026 15:26:38 +0200 Subject: [PATCH] Close WARDEN-WP-0039 with fetch-pin receipts; activate audit-core-senders pointer - 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 Assistant: claude-code Assistant-Model: opus Assistant-Process: 427672@bnt-lap001 Assistant-Session: a0a2367e-4697-440c-a4e5-9713c009f6d8 --- registry/routing/catalog.yaml | 20 ++++++++++---- wiki/CredentialRouting.md | 1 + wiki/playbooks/audit-core-senders.md | 9 ++++--- .../WARDEN-WP-0039-explicit-policy-refusal.md | 27 ++++++++++++++++--- ...EN-WP-0044-security-case-follow-through.md | 8 ++++++ 5 files changed, 52 insertions(+), 13 deletions(-) diff --git a/registry/routing/catalog.yaml b/registry/routing/catalog.yaml index 7767c44..c76ffbf 100644 --- a/registry/routing/catalog.yaml +++ b/registry/routing/catalog.yaml @@ -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 diff --git a/wiki/CredentialRouting.md b/wiki/CredentialRouting.md index 85e82d9..6afff20 100644 --- a/wiki/CredentialRouting.md +++ b/wiki/CredentialRouting.md @@ -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`. diff --git a/wiki/playbooks/audit-core-senders.md b/wiki/playbooks/audit-core-senders.md index b3676be..85c878d 100644 --- a/wiki/playbooks/audit-core-senders.md +++ b/wiki/playbooks/audit-core-senders.md @@ -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 diff --git a/workplans/WARDEN-WP-0039-explicit-policy-refusal.md b/workplans/WARDEN-WP-0039-explicit-policy-refusal.md index 0813af7..ca0828d 100644 --- a/workplans/WARDEN-WP-0039-explicit-policy-refusal.md +++ b/workplans/WARDEN-WP-0039-explicit-policy-refusal.md @@ -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. diff --git a/workplans/WARDEN-WP-0044-security-case-follow-through.md b/workplans/WARDEN-WP-0044-security-case-follow-through.md index 679e9e9..e5f56b4 100644 --- a/workplans/WARDEN-WP-0044-security-case-follow-through.md +++ b/workplans/WARDEN-WP-0044-security-case-follow-through.md @@ -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