4a284f0a3b
Founder direction 2026-10-06 and ops-mason plan keycape-secrets-engine-openbao-client-custody (658cdbc, MASON-WP-0009): the client secret lives only in OpenBao. - CCR-2026-0033: consumer file and secrets-engine D1-D4 removed; KV metadata declared (cas_required, max_versions=2, delete_version_after=0s, custom_metadata); target.domain infotech; live order and roll-forward rollback revised; status stays proposed. - New sibling CCR-2026-0034 + policy: attended OIDC operator reader on auth/netkingdom, read data path + revoke-self only, 5m/4 uses, no default policy, bound groups=net-kingdom-admins and /assurance/level=aal2 (KeyCape 7d96ee4). Proposed, bound claims unconfirmed (founder item for both readers). - credential-change.py: OIDC roles carry token_max_ttl/explicit_max_ttl/no_default_policy/ num_uses/type and bound_claims_type (string only); token_revoke_self policy option; validated openbao.kv_metadata. Tests added. - Custody child: consumer write and check-secret-file removed; cas=0 create / --rotate cas=<current>; compare-before-write metadata put; refusals unchanged. - Founder runbook (keycape/founder-runbook.md), window docs, RPF-WP-0035-T09 (waits on A1/A2/A3). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 132360@bnt-lap001 Assistant-Session: 769b1afd-4330-4c86-96b2-e510e26db42b
101 lines
7.8 KiB
Markdown
101 lines
7.8 KiB
Markdown
# Remaining dependency requirements — 2026-10-04
|
|
|
|
Review scope: RPF-WP-0050-T03, RPF-WP-0051-T02/T03 and the selected
|
|
RPF-WP-0035-T02 service-login lane. Source work is implemented where independent
|
|
of receiving-owner facts. Both preparation workplans are blocked on the
|
|
deliveries below. Completed design judgments are retained.
|
|
|
|
| Platform task | Receiving repo / owner task | Required independent delivery | Reopen condition |
|
|
| --- | --- | --- | --- |
|
|
| RPF-WP-0051-T02 | informed-decision / source phase of INFD-WP-0005-T05 | Process-owned private listener and explicit runtime configuration consuming compose_intake; authenticated bounded TokenReview transport using API-server CA; exact owner deploy renderer with private Service, NetworkPolicy, TokenReview RBAC and projected registries; final immutable image/config/source | Accept source composition and publication receipt, reviewed deployment proposal and named native verification/abort attendance. Do not require this owner's entire live T05 completion as a predecessor. |
|
|
| RPF-WP-0051-T03 | informed-decision receiving runtime; founder execution gate | Complete T02 source packet, approve exact final live action, then native ESO/auth/file/exchange and revocation/rotation/cleanup receipts | Native delivery and owner runtime acceptance, after platform metadata and separately approved runtime promotion. Source proofs are already complete. |
|
|
| RPF-WP-0035-T02 | secrets-engine / service-auth source acceptance in SECRETS-WP-0008-T06 | Explicit consumer host, protected file path and owner, mode-0600 delivery mechanism, refresh/rotation/revocation ownership and bounded validation interface | Source acceptance of those coordinates, independent of obtaining a working OpenBao service token. The entire live consumer task must not precede platform login provisioning. |
|
|
| RPF-WP-0035-T02 | key-cape / KEY-WP-0037-T02/T03/T04; net-kingdom deployment authority | Accept proposed issuer coordinates and separate consumer delivery; reviewed single-client/env-preserving registration operation with immutable image/config; independently approved custody and actual registration/issuance receipts | Protected custody, real registration and validated provider claims are returned. Platform then performs its separately approved isolated JWT mount/role/self-policy operation and login proof. |
|
|
| RPF-WP-0050-T03 | user-engine / USER-WP-0035-T02 and provider owner | Provider-supported single-use password-setup-link delivery contract and intended-recipient evidence; retained value-safe failure/retry behavior | Real handoff receipt. SMTP and invitation delivery already exist and are not reprovisioned. |
|
|
|
|
## Delivered owner work and platform checks
|
|
|
|
Informed-decision source acceptance: implementation
|
|
`eb9614c2677c7f07c9d78eee7543f95f329d2c83`, exact-primary receipt
|
|
`f06b7e9c53d3477f1e690ed8259f2eaab3661f91`. Requests/replies:
|
|
`17bcfb39-f8c0-4cda-acce-de7af6d0afbc` and
|
|
`d304e328-1e77-4a02-ae47-783a7290b6ce`. Its RequesterTokenProvider and
|
|
compose_intake are implemented with 37 focused owner tests. Exact source
|
|
binding/mount acceptance is supplied; live claims are not confirmed.
|
|
|
|
Platform independently verified railiance01's node address and the actual
|
|
external-secrets controller ServiceAccount, then checked permission to create
|
|
serviceaccounts/token in informed-decision through SubjectAccessReview.
|
|
The explicit subresource query returned yes. Receipt:
|
|
`docs/evidence/2026-10-04-requester-eso-tokenrequest-review.json`. This is an
|
|
authorization check; no token was minted and it does not prove Secret delivery.
|
|
The earlier slash-resource spelling gave a different result and is not accepted
|
|
as the TokenRequest receipt. The explicit subresource query is authoritative.
|
|
|
|
KeyCape source packet: `44cc067aa2c7dadffc75b631baa221a5f5caa531`;
|
|
managed IDs/index locally at `f485d6fe9c7389b7f29d97e5da51b14eb0692eb3`.
|
|
Replies `58826056-55f2-4300-9b42-05ceeec9c26a` and
|
|
`eb20a78c-0b9b-41e6-b349-dfaa9873633b` name the real owner tasks. Its latest
|
|
exact-primary sync is pending: Repo Manager refused grandfathered
|
|
ADHOC-2026-09-27-T02 without UUID. KeyCape/repo-manager must reconcile the
|
|
source identity through the required scoped decision, then return an applied/noop
|
|
receipt for the actual current commit. Platform does not invent UUIDs or bypass
|
|
the refusal. This is separate from actual provider registration/custody.
|
|
|
|
## Implemented platform issuer-reader preparation
|
|
|
|
The KeyCape packet's candidate path `platform/services/keycape/secrets-engine-openbao`
|
|
is outside the platform-mount applier scope (`platform/workloads/` only) and was
|
|
corrected on 2026-10-06 to `platform/workloads/keycape/secrets-engine-openbao`,
|
|
field CLIENT_SECRET.
|
|
|
|
**Revised 2026-10-06 (founder direction: the secret lives only in OpenBao; ops-mason
|
|
plan `keycape-secrets-engine-openbao-client-custody`, 658cdbc, MASON-WP-0009).**
|
|
The secrets-engine consumer file and secrets-engine D1-D4 are withdrawn. Two readers:
|
|
|
|
- Issuer: CCR-2026-0033, unchanged ESO reader. Policy
|
|
`workload-kv-read-keycape-secrets-engine-openbao-eso`, Kubernetes role
|
|
`external-secrets-keycape-secrets-engine-openbao` (external-secrets/external-secrets,
|
|
audience openbao, 15m, no default policy). The store admits sso only; target Secret
|
|
`sso/keycape-secrets-engine-openbao-client` key `client-secret`. It must stay on
|
|
Kubernetes auth.
|
|
- Operator: sibling CCR-2026-0034, OIDC role
|
|
`keycape-secrets-engine-openbao-operator-workload-kv-read` on `auth/netkingdom`.
|
|
Policy `workload-kv-read-keycape-secrets-engine-openbao-operator` grants read on
|
|
the data path and update on `auth/token/revoke-self` only. The token is 5m, 4 uses,
|
|
service type, with no default policy. Bound claims are `groups=net-kingdom-admins`
|
|
and `/assurance/level=aal2` (KeyCape 7d96ee4: MFA is not pinned on the openbao-admin
|
|
client). secrets-engine reads the value into memory per command, with no copy
|
|
at rest.
|
|
|
|
CCR-2026-0033 now declares the KV metadata: `cas_required=true`, `max_versions=2`,
|
|
`delete_version_after=0s`, and custom_metadata as in the plan. Its target.domain is
|
|
corrected to infotech. The custody child
|
|
`scripts/keycape_secrets_engine_openbao_custody.py` (source only, never run) writes
|
|
KV with `cas=0`, or with `cas=<current>` under `--rotate`, then compares the
|
|
metadata before it writes. It writes no consumer file. Both CCRs remain proposed with
|
|
bound claims unconfirmed. Confirming them is a founder item for both readers.
|
|
|
|
Founder approvals: A1 design, A2 both CCRs, A3 custody-child decision id (not
|
|
632a8893). Live order: custody child → platform applies policies/roles/ESO (Secret
|
|
sso/keycape-secrets-engine-openbao-client exists) → NetKingdom env patch (NK-WP-0046)
|
|
→ KeyCape registration merge (KEY-WP-0037-T03) → KeyCape restart immediately → live
|
|
issuance check (KEY-WP-0037-T04) → OpenBao JWT role/login proof (RPF-WP-0035-T02).
|
|
Exact founder commands, including the metadata-only survey:
|
|
`keycape/founder-runbook.md`. Payloads and ESO stay outside active GitOps in this
|
|
window's `keycape/` directory. No value exists by implication of these drafts.
|
|
|
|
## Dependency boundary
|
|
|
|
Owner source readiness precedes platform promotion. Platform native delivery
|
|
proof follows its own authorized apply, and receiving live acceptance follows
|
|
that delivery. Requiring a receiving repo's full live completion before platform
|
|
supplies its credential would create a mutual wait. Where an owner composite
|
|
task includes both phases, the wait is qualified as `message-from:<owner>` for
|
|
the exact independent source receipt until that owner names a separate source
|
|
task; no fabricated task ID or complete-task dependency is introduced.
|
|
|
|
Once source deliveries arrive, reopen only the affected platform task. The
|
|
founder-approved informed-decision design needs no repeat decision unless scope
|
|
changes. Live actions still require a fresh reviewed execution packet and go;
|
|
the historical 10:00 preparation window is not a standing execution grant.
|