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

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