RPF-WP-0069-T05: draft CCR-2026-0063 for the bounded-executor audit sender.
All checks were successful
CCR intake gate / gate (push) Successful in 2m12s
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s

Audit-core admitted nk-bounded-executor (AUDIT-WP-0018-T02). Proposed custody
at platform/workloads/net-kingdom/bounded-executor/audit-sender with an exact
data-read policy, ESO reader role and coding-agent fence, in the CCR-2026-0022
shape with audit-core's secret_policy reject. T03 status refreshed: setup done
via net-kingdom executor-lanes.py, per-window role waits on NK-WP-0056-T06.

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 509845@bnt-lap001
Assistant-Session: ed7a7d95-d8eb-455c-b594-963fb1830f76
This commit is contained in:
codex 2026-11-03 23:07:06 +01:00
parent 0e98465c6e
commit 88071e79e2
4 changed files with 171 additions and 3 deletions

View file

@ -0,0 +1,130 @@
id: CCR-2026-0063
kind: credential-change-request
schema_version: 1
request_type: workload-kv-read
title: NetKingdom bounded-executor audit sender custody and delivery
status: proposed
created: '2026-11-03'
updated: '2026-11-03'
requester:
agent: claude-code
reason: RPF-WP-0069-T05 / NK-WP-0056-T15 / NK-WP-0040. Audit-core admitted and named
the sender nk-bounded-executor (AUDIT-WP-0018-T02, deploy/senders-scope.json) and
asks railiance-platform for custody of its bearer, ESO-projected to sso
(audit-core docs/bounded-executor-receipts.md). Drafted by the railiance-platform
worker in the CCR-2026-0021/0022 shape; not approved.
review:
required: true
required_approvers:
- platform-owner
- audit-core-owner
- net-kingdom-owner
comments: []
target:
domain: infotech
tenant: platform
workload: net-kingdom-bounded-executor
environment: production
purpose: 'Provide only the audit-core sender nk-bounded-executor with its registry
scope as declared by audit-core: source net-kingdom.bounded-executor, tenants [platform],
may_write true, may_read false, evidence_kind load-bearing, secret_policy reject,
closing class execution.run.started -> execution.attribution.receipt within 7200
s. Preserve the existing receiver registry and every other sender.'
openbao:
mount: platform
kv_path: platform/workloads/net-kingdom/bounded-executor/audit-sender
fields:
- AUDIT_TOKEN
- CUSTODY_REQUEST
policy_name: workload-kv-read-nk-bind-executor-audit
policy_file: openbao/policies/workload-kv-read-nk-bind-executor-audit.hcl
metadata_read: false
auth:
method: kubernetes
mount: kubernetes
role: external-secrets-nk-bind-executor-audit
bound_claims:
service_account_names:
- external-secrets
service_account_namespaces:
- external-secrets
bound_claims_confirmed: false
policies:
- workload-kv-read-nk-bind-executor-audit
ttl: 15m
access_frontdoor:
type: external-secrets
catalog_id: nk-bind-executor-audit
readiness: pending-review
resolvable: false
delivery:
surface: external-secrets
namespace: sso
service_account: nk-bind-executor
target: 'ClusterSecretStore openbao-nk-bind-executor-audit restricted to namespace
sso; ExternalSecret and Secret sso/nk-bind-executor-audit, key audit-token, mounted
as a file in the executor pod (sso/nk-bind-executor, uid bd15569c). The store and
ExternalSecret manifests belong in the reviewed rapp-* package next to the executor,
as for CCR-2026-0053; this request creates none.'
receiver: POST /v1/events to http://audit-core.audit-core.svc.cluster.local:8080;
envelope source equals the sender scope source; Idempotency-Key is the envelope
id and correlation_id is the run_id. Ingress audit-core-nk-bounded-executor-ingress
admits only executor pods in sso.
risk:
classification: high
notes:
- The bearer permits append for its exact source and tenant only, never reading
or changing stored evidence. It is not an OpenBao identity.
- secret_policy is reject, as audit-core registered it; this supersedes redact in
the 2026-10-31 owner answer. The overlay may tighten it but never relax it.
- The registry update reads existing sender credentials inside the attended platform
process only. No registry is delivered to a producer.
- OpenBao login TTL limits the ESO reader session, not the audit bearer. Revocation
must remove the sender token from the receiver registry and prove refusal.
- The sso namespace also runs Authelia, LLDAP and KeyCape. The Secret is readable
by any workload allowed to read Secrets in sso; only the executor pod mounts it.
- 'Open for net-kingdom-owner review: NK-WP-0056-T15 prefers an OpenBao read role
for the executor over an ESO Secret. This request follows the shape audit-core
and the platform owner answer agreed (ESO, like the other in-cluster senders);
a direct read role would need a changed request.'
- The new paths extend the coding-agent deny boundary (agent-high-risk-boundary).
No existing high-risk grant is widened.
verification:
positive:
- Independent CAS=0 token creation and exact sender merge with registry-version
compare-and-set; repeated runs preserve all existing senders and registry fields.
- ESO delivers only AUDIT_TOKEN into sso/nk-bind-executor-audit:audit-token; source
and receiver copies agree without displaying values.
- The deployed receiver accepts a synthetic started event and receipt for the exact
source and tenant (202), returns 200 for a duplicate and 409 for a reused run_id
with a different body.
negative:
- Sibling sender path, full registry and parent listing are denied to the ESO reader.
Wrong service account or namespace fails; a disallowed store namespace gets no
Secret.
- Receiver refuses a wrong source or tenant, every read route, a secret-shaped step
check (400) and a revoked token. No existing sender is removed or re-scoped.
- A proposed or altered CCR, stale registry version, token collision or partial
custody refuses without overwriting.
activation_conditions:
- All three named owner reviews approve before any native credential mutation.
- Audit-core's founder-run rollout of the sender scope ConfigMap and the ingress
NetworkPolicy is done, and the executor accepts 202 (NK-WP-0056-T15).
- The rapp-* package carries the ClusterSecretStore and ExternalSecret; the binding
is confirmed against it.
- Use the Warden attended platform-admin login envelope; preserve an independent
receipt and revoke the session on exit.
- Record native positive and negative evidence before declaring verified or active.
Custody alone admits no executor run; that stays with the founder-signed admission
(NK-WP-0056-T06).
lifecycle:
deactivate: Stop the executor; remove only its token from the registry using CAS
and reload and verify receiver refusal. Then detach the reader policy and remove
the ExternalSecret and projection, keeping KV versions for investigation. Do not
delete audit events or other sender entries.
rotate: 'Reviewed overlap-first rotation: append a replacement to this sender only,
deliver it, prove acceptance, then remove the predecessor and prove refusal. The
first-provision helper refuses rotation and unexpected existing values.'
compromised: Stop the executor and revoke the exact receiver token first; inspect
events from net-kingdom.bounded-executor, rotate through a separate reviewed action,
and keep the independent audit trail.

View file

@ -144,6 +144,10 @@ path "platform/metadata/workloads/approval-engine/audit-sender" { capabilities =
path "platform/data/workloads/informed-decision/audit-sender" { capabilities = ["deny"] }
path "platform/metadata/workloads/informed-decision/audit-sender" { capabilities = ["deny"] }
# Proposed bounded-executor audit sender custody: CCR-2026-0063 (RPF-WP-0069-T05).
path "platform/data/workloads/net-kingdom/bounded-executor/audit-sender" { capabilities = ["deny"] }
path "platform/metadata/workloads/net-kingdom/bounded-executor/audit-sender" { capabilities = ["deny"] }
# CCR-2026-0039: coding-agent denies for platform/workloads/coulomb/fluid-telegram/hall-of-helix (data and metadata).
path "platform/data/workloads/coulomb/fluid-telegram/hall-of-helix/operator-app" { capabilities = ["deny"] }
path "platform/metadata/workloads/coulomb/fluid-telegram/hall-of-helix/operator-app" { capabilities = ["deny"] }

View file

@ -0,0 +1,3 @@
path "platform/data/workloads/net-kingdom/bounded-executor/audit-sender" {
capabilities = ["read"]
}

View file

@ -9,7 +9,7 @@ flavor: implementation
owner: claude
topic_slug: railiance
created: "2026-10-31"
updated: "2026-11-01"
updated: "2026-11-03"
related:
- NK-WP-0056
- NK-WP-0040
@ -63,6 +63,8 @@ id: RPF-WP-0069-T03
status: wait
priority: high
depends_on: [RPF-WP-0069-T02]
blocked_on: dependency
blocking_reason: "Per-window role creation, run receipts and deletion happen in the first founder-admitted executor run (NK-WP-0056-T06)"
state_hub_task_id: "6b456804-c408-53bf-8e1d-49723108fca6"
```
@ -71,6 +73,15 @@ re-checks the coding-agent fence, applies policy and role, and records value-fre
negative receipts. This needs an owner setup script modelled on net-kingdom `bind-lane.py`
setup/verify; write it once approval exists. The founder runs it.
2026-11-03 status: the setup half is done. The owner script is net-kingdom
`tools/service-binds/executor-lanes.py`, not a new script here. On 2026-10-31 the founder
ran it: the CCR-2026-0058 policy was applied, `cas_required` was set on the svc-authelia key,
and the coding-agent fence was re-checked (CCR-2026-0058 evidence, net-kingdom `ef6284c`).
Under the window-scoped decision (c29c6eda), no write role exists between runs. What remains
is the per-window part: create the role for an admitted window, record positive and negative
receipts, and delete the role after the run's receipt. That happens in the first admitted run,
NK-WP-0056-T06, which is still `todo` and depends on T15, T16 and T19 on the net-kingdom side.
## Journey-secret read lane for the executor (NK-WP-0056-T10)
```task
@ -112,8 +123,8 @@ CCR-2026-0057's `runtime_access: false`. Waits for T10 scheduling and the Servic
id: RPF-WP-0069-T05
status: wait
priority: medium
blocked_on: dependency
blocking_reason: "audit-core admits and names the sender (AUDIT-WP-0018-T02)"
blocked_on: human
blocking_reason: "Owner reviews of CCR-2026-0063 (platform-owner, audit-core-owner, net-kingdom-owner)"
state_hub_task_id: "5c582aef-ee9d-56ab-a4eb-2019933f00ac"
```
@ -121,6 +132,26 @@ After audit-core admits the sender and names it, draft a `workload-kv-read` CCR
CCR-2026-0021/0022 shape: custody `platform/workloads/net-kingdom/bounded-executor/audit-sender`,
ESO into `sso/nk-bind-executor-audit`, ClusterSecretStore restricted to `sso`.
2026-11-03: audit-core admitted the sender in AUDIT-WP-0018-T02 as `nk-bounded-executor`:
source `net-kingdom.bounded-executor`, tenants `[platform]`, write only, `load-bearing`,
`secret_policy: reject`, closing class `started -> receipt` within 7200 s.
**CCR-2026-0063** is drafted as `proposed`. It validates, with only the expected
unconfirmed-binding warning, and its policy file matches the generated policy.
- Policy `openbao/policies/workload-kv-read-nk-bind-executor-audit.hcl`: data read on the
exact path only.
- Role `external-secrets-nk-bind-executor-audit`: `external-secrets/external-secrets`.
- Coding-agent deny on the data and metadata paths in `agent-high-risk-boundary.hcl`. This is a
source change; it is applied in the attended session.
- `secret_policy` follows audit-core's `reject`, not the `redact` in our 2026-10-31 answer.
- The ClusterSecretStore and ExternalSecret belong in the rapp-* package, as for
CCR-2026-0053.
Open for the net-kingdom-owner review: NK-WP-0056-T15 prefers an OpenBao read role over an
ESO Secret, while audit-core and our answer specify ESO. The CCR records this. Approval,
binding confirmation and the attended seed follow, after audit-core's founder-run rollout and
the executor's 202 fix.
## LLDAP credential custody for the executor
```task