tegwick
e06d7fc390
Assistant: codex Assistant-Model: gpt-5.6-luna Assistant-Session: 01a07ff8-19d0-7820-b4d0-1353833cb7fc
238 lines
11 KiB
Markdown
238 lines
11 KiB
Markdown
---
|
|
id: RPF-WP-0035
|
|
type: workplan
|
|
title: "Implement reviewed credential lanes with separate owner gates"
|
|
domain: financials
|
|
repo: railiance-platform
|
|
status: blocked
|
|
owner: codex
|
|
created: "2026-09-05"
|
|
updated: "2026-09-08"
|
|
related:
|
|
- RPF-WP-0032
|
|
- RPF-WP-0033
|
|
- RPF-WP-0034
|
|
state_hub_workstream_id: "975db491-5412-5e27-8e34-14a2417bb039"
|
|
---
|
|
|
|
# Credential lane implementation
|
|
|
|
One S3 queue for three designed lanes; each task keeps its own approval,
|
|
execution and closure boundary. This replaces the implementation tasks in the
|
|
three completed design workplans, not the designs themselves. No approval is
|
|
inherited by consolidation. INTENT binding: secure custody, dependable delivery,
|
|
stable consumer interfaces. Incident custody remains in RPF-WP-0027/0029.
|
|
|
|
## Consolidate completed designs and owner dependencies
|
|
|
|
```task
|
|
id: RPF-WP-0035-T01
|
|
status: done
|
|
priority: medium
|
|
state_hub_task_id: "0f3606bb-e95b-5484-8a57-bcdd6e3916fd"
|
|
```
|
|
|
|
Completed 2026-09-05. Preserved the three designs under
|
|
`docs/credential-lane-designs/`, identified native owner responsibilities and
|
|
linked each superseded task below. Owners have not been sent new requests and
|
|
no new external acceptance is claimed. STATE-WP-0085-T09 is already done;
|
|
the signing dependency belongs to the proposed FLEX-WP-0020-T05 cutover.
|
|
|
|
## Accept and provision secrets-engine service JWT login
|
|
|
|
```task
|
|
id: RPF-WP-0035-T02
|
|
status: wait
|
|
priority: high
|
|
state_hub_task_id: "e0c82ea9-05a5-537e-8fbf-67534263572e"
|
|
```
|
|
|
|
Supersedes RPF-WP-0032-T02. Design:
|
|
`docs/credential-lane-designs/secrets-engine-service-jwt.md`.
|
|
|
|
Platform owns the exact JWT mount/role/policy, effective-policy negative tests
|
|
and a metadata-only custody receipt. KeyCape owns issuer/JWKS and service
|
|
registration (KEY-WP-0009); secrets-engine owns service authentication and
|
|
authority consumption (SECRETS-WP-0008-T06, SECRETS-WP-0007-T04).
|
|
|
|
**Unblock:** confirmed HTTPS issuer/JWKS, exact claims and audience, consumer
|
|
readiness, approved source and attended apply authority. A service login does
|
|
not grant lane mutation authority. Do not build another identity provider or
|
|
lifecycle engine here.
|
|
|
|
**Done when:** approved exact role succeeds for the intended service, wrong
|
|
issuer/audience/subject/claims and unrelated secret access fail, bounded TTL
|
|
and revocation are proven, the consumer explicitly opts into the verified
|
|
contract, and rollback/cleanup receipts contain no secret material.
|
|
|
|
## Implement the platform operator-write CCR contract and Fluid lane
|
|
|
|
```task
|
|
id: RPF-WP-0035-T03
|
|
status: wait
|
|
priority: high
|
|
state_hub_task_id: "f47e5bc5-6f3c-54bb-aa35-260ad03892ba"
|
|
```
|
|
|
|
Supersedes RPF-WP-0033-T02. Design:
|
|
`docs/credential-lane-designs/fluid-telegram-operator-kv.md`.
|
|
|
|
Platform owns the per-path capability schema/validator, exact OpenBao policy
|
|
and accepted custody coordinates. MASON-WP-0005 owns construction coordination
|
|
and engine integration; KeyCape/NetKingdom own OIDC/MFA and group membership;
|
|
FT-WP-0002 owns client CAS, prefix correction, output containment and Telegram
|
|
application acceptance. Retain the existing read-only CCR semantics.
|
|
|
|
**Unblock:** accept tenant/path and per-entry field/capability matrix; confirm
|
|
actual group/assurance and callbacks, reviewed construction contract and writer
|
|
authority. Contract review can proceed without a live credential; the final
|
|
schema cannot be treated as accepted solely because a draft exists.
|
|
|
|
**Done when:** validation rejects broad/unsupported grants, the consumer proves
|
|
CAS=0 first-write behavior and no value output, approved identities can perform
|
|
only the exact matrix, negative/expiry/revocation checks pass, custody is seeded
|
|
through the separate writer, and the verified route has a safe handoff receipt.
|
|
The unattended adapter remains a separate demand and gets no operator session.
|
|
|
|
## Accept the needed signing lane and deliver it to the owning runtime
|
|
|
|
```task
|
|
id: RPF-WP-0035-T04
|
|
status: done
|
|
priority: medium
|
|
state_hub_task_id: "35a85846-61d5-54ce-8b18-ede45733d53c"
|
|
```
|
|
|
|
Supersedes RPF-WP-0034-T02. Design:
|
|
`docs/credential-lane-designs/state-hub-preflight-signing.md`.
|
|
|
|
Platform owns signing-key custody, exact read policy/role and scoped delivery
|
|
acceptance. State Hub owns API chart/env wiring, all-replica rotation fencing
|
|
and health. FLEX-WP-0020-T05 owns the rename preflight/cutover dependency;
|
|
STATE-WP-0085-T09's adoption-plan delivery is already complete.
|
|
|
|
**Unblock:** State Hub/repo-manager and the consuming migration owner confirm
|
|
that this transitional State Hub lane is still needed during retirement;
|
|
record the target runtime, namespace/SA/auth audience and an executable
|
|
rotation fence, plus approved writer and deployment window. Do not broaden the
|
|
lane into a general repository-rename authority or provision for a stale demand.
|
|
|
|
**Done when:** protected one-time generation, API-only ESO delivery, negative
|
|
access checks and a non-mutating signed preflight pass; every API replica uses
|
|
the accepted version; rotation/invalidation and recovery are evidenced. No
|
|
repository rename is part of S3 lane acceptance. If demand is withdrawn, record
|
|
the owning decision and cancel this task explicitly rather than provision it.
|
|
|
|
2026-09-05 continuation: verified the live primary cluster identity and healthy
|
|
single API replica; the signing ExternalSecret is still absent. Added a writer
|
|
guard against wrong-cluster kubeconfigs before any OpenBao access. The default
|
|
workstation kubeconfig's local port-forward listener was unavailable. Activation
|
|
still needs the contained attended OIDC/MFA login and the acceptance evidence
|
|
above; source preparation is not live completion. See
|
|
`history/2026-09-05-preflight-signing-activation-readiness.md`.
|
|
|
|
|
|
Completed 2026-09-05: user-led attended activation generated version 1 and
|
|
rotated to version 2 with every API replica stopped. Exact access and negative
|
|
identity checks passed; ESO delivery and API-only exposure passed; the recovered
|
|
single API replica accepts new signed preflight and rejects its predecessor by
|
|
signature, with healthy primary identity and no preflight blockers. State Hub
|
|
chart commit `49e3182`, Helm revision 59. No repository rename executed.
|
|
Evidence: `docs/evidence/RPF-WP-0035-T04-signing-activation-2026-09-05.json`;
|
|
closure: `history/2026-09-05-preflight-signing-activation-complete.md`.
|
|
|
|
## Admit KeyCape approval-engine client custody and delivery
|
|
|
|
```task
|
|
id: RPF-WP-0035-T05
|
|
status: wait
|
|
priority: high
|
|
state_hub_task_id: "e15d62c9-e5da-5721-a135-87c050f7851c"
|
|
```
|
|
|
|
Answers KEY-WP-0013-T02 (State Hub message
|
|
`278a3ebe-b529-49f6-bd1a-e3ebcf318260`). Admission:
|
|
`docs/credential-lane-designs/keycape-approval-clients.md`; requests
|
|
`CCR-2026-0017` (secrets-engine-approval) and `CCR-2026-0018`
|
|
(approval-engine-operator).
|
|
|
|
Platform owns the two custody paths, exact-path read policies, Kubernetes auth
|
|
roles and the KeyCape-side ESO delivery. KeyCape owns the client registrations,
|
|
issuance, claim set and disablement; approval-engine owns approval semantics and
|
|
audit of emitted actions.
|
|
|
|
2026-09-08 admission response: both proposed KV paths confirmed unchanged; field
|
|
`client_secret` corrected to `CLIENT_SECRET` for the uppercase KV convention and
|
|
CCR validator. Kubernetes delivery references confirmed against the live `sso`
|
|
namespace, which already resolves `KEYCAPE_RAPP_QONTO_CLIENT_SECRET` through the
|
|
same `secretKeyRef{key: client-secret}` shape on image `main-153258b`. Attended
|
|
authority named as the governed `openbao-platform-admin-login` lane
|
|
(`founder_required`); KeyCape's refusal to treat its generic `warden plan`
|
|
database match as authorization was correct. Rollout agreed as one attended
|
|
session with the KeyCape reading build pinned but undeployed, ordered after the
|
|
Authelia issuer precondition in message `c8b1ad10-dae8-48fb-a0ea-7e2a101c54bf`.
|
|
Policies, ClusterSecretStores and ExternalSecrets are written and validated,
|
|
none applied.
|
|
|
|
**Unblock:** owner approval of both CCRs, a KeyCape image that reads both
|
|
environment names, the settled Authelia `iss` pin, and a founder-attended window
|
|
date. Verifier-side custody only — no client-side read lane is admitted, and no
|
|
scope beyond the two declared sets.
|
|
|
|
**Done when:** both CCRs are approved, the attended window seeds both KV paths
|
|
with CAS=0, policies/roles/stores/ExternalSecrets apply and sync, the KeyCape
|
|
build resolves both environment names, KeyCape evidences live JWKS signature and
|
|
exact claim bindings with excess scopes denied (operator `consume`, human
|
|
`consume`), platform evidences cross-path/wrong-identity/out-of-namespace denial,
|
|
and every receipt is metadata-only. If either registration is abandoned, KeyCape
|
|
disables it before the KV version is destroyed.
|
|
|
|
### 2026-09-08 actual upstream issuer returned
|
|
|
|
The admitted KeyCape one-shot probe verified the actual signed upstream issuer
|
|
as **`https://auth.coulomb.social`** at 21:44:44 UTC. Signature, audience,
|
|
validity window and nonce checks passed and the pinned Job exited 0. All
|
|
five temporary resources and the Pod were removed; normal KeyCape Deployment
|
|
and config Secret metadata are unchanged. See
|
|
`docs/evidence/2026-09-08-keycape-upstream-issuer-proof.json`.
|
|
|
|
T05's unknown-issuer input is resolved. The configuration owner still ensures
|
|
`authelia.issuer` equals that exact HTTPS value before the custody window.
|
|
Both CCRs remain proposed and await the named reviews; this probe grants no
|
|
custody mutation or client-side read. Keep the current authority preflight and
|
|
this signed-token proof as separate receipts. Live ESO/client/approval and
|
|
separate audit/client-side custody acceptance remain open.
|
|
|
|
## Dependency review — 2026-09-06
|
|
|
|
SECRETS-WP-0008-T02 now records the local PIP claim/validation join implemented
|
|
and tested. Its remaining gate is the unreachable approval-engine claim endpoint
|
|
and access-engine Check (SECRETS-WP-0007-T04). Do not carry forward the old local
|
|
stub as a blocker. T02 still needs the accepted service issuer/JWKS, claims,
|
|
audience and consumer binding. T03 still needs confirmed operator group/tenant
|
|
and consumer semantics; T04 is already complete. No new owner acceptance inferred.
|
|
|
|
|
|
### 2026-09-08 attended capability preflight
|
|
|
|
HFACT-WP-0001's continued execution verified the existing first-provision
|
|
front door without provisioning anything. `warden plan` selected
|
|
`openbao-platform-admin-login` / founder_required / one oidc_login. The native
|
|
`scripts/openbao-attended-exec.py` supplied the existing WSL browser launcher;
|
|
a direct attempt had no launcher and failed before handoff. Its first revocation
|
|
result was unconfirmed and is preserved in the receipt rather than silently
|
|
reclassified. The two subsequent contained sessions completed self-revocation
|
|
and helper cleanup.
|
|
|
|
`scripts/keycape-approval-custody-preflight.py --receipt <new-private-file>` is
|
|
a silent, read-only command for that envelope. The installed Bao CLI supports
|
|
one path per `token capabilities` call; the final run used six single-path calls.
|
|
Create/update authority is present on both exact policy paths, both Kubernetes
|
|
auth-role paths and both KV data paths from CCR-2026-0017/0018. This is authority
|
|
metadata, not a secret-data read or policy/role/KV mutation. Receipt:
|
|
`docs/evidence/2026-09-08-keycape-approval-custody-preflight.json`.
|
|
|
|
T05 remains wait: both CCRs are still proposed, the actual upstream ID-token
|
|
issuer precondition remains open, and no verifier-side credential is provisioned.
|
|
Client-side retrieval and audit-sender custody are still separate owner returns.
|
|
The capability receipt is not a review approval or service readiness proof.
|