railiance-platform/workplans/RPF-WP-0035-credential-lane-implementation.md

id	type	title	domain	repo	status	owner	created	updated	related	state_hub_workstream_id
RPF-WP-0035	workplan	Implement reviewed credential lanes with separate owner gates	financials	railiance-platform	blocked	codex	2026-09-05	2026-09-09	RPF-WP-0032 RPF-WP-0033 RPF-WP-0034	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

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

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

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

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

id: RPF-WP-0035-T05
status: done
needs_human: false
intervention_note: ""
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.

2026-09-09 configuration and review-queue return: NetKingdom pinned the verified HTTPS issuer, using an atomic UID/resourceVersion test and independent readback. Secret revision 58713343; unrelated configuration and signing key unchanged; no Deployment rollout. Receipt: docs/evidence/2026-09-09-keycape-upstream-issuer-pin.json.

The two existing CCRs remain proposed. They now link to concrete pending review decisions, with platform-operator and key-cape-owner named explicitly. See docs/credential-lane-designs/keycape-approval-clients-review.md. T05 owns this human dependency; HFACT consumes it without a duplicate approval request. Custody/ESO activation, client verification and the separate client-side/audit lanes remain open. Current CLI apply plans refuse the proposed requests.

2026-09-09 admission: the user explicitly approved both CCRs in the named platform-operator and key-cape-owner roles. Both source requests are approved and both linked Hub decisions are resolved. Receipt: docs/evidence/2026-09-09-keycape-approval-admission.json. The completed review intervention is cleared; T05 is progress while the contained first-provision procedure is exercised and the admitted attended rollout is carried through. Verifier-side scope, separate client-side/audit lanes and live acceptance remain as defined in the reviewed requests.

2026-09-09 verifier-side return: both CCRs are verified after recorded user approval, CAS=0 version-1 custody, native read/auth denials and revocation, Valid stores, SecretSynced delivery, compatible KeyCape rollout and live positive/negative service checks. Existing human OpenBao login passed again on the new image. Receipt: docs/evidence/2026-09-09-keycape-verifier-admission.json. Failed attempts restored the compatible configuration/image and detached delivery; final resume reused version 1.

T05 is done against its verifier-only acceptance criteria. Its former "remains progress for client-side reads" statement expanded the task past its reviewed scope; that residual now has the live owner task RPF-WP-0035-T06 below. Neither Warden fetch selector is resolvable through these verifier-only CCRs. Do not re-request the completed two named reviews or reseed these paths. Rotation is a distinct, version-guarded operation.

Admit the separate approval client-side readers

id: RPF-WP-0035-T06
status: wait
priority: high
needs_human: false
intervention_note: ""
state_hub_task_id: "68bff751-e48b-548b-8fb4-dfb3b16210c2"

Residual handoff from RPF-WP-0035-T05; consumes the completed verifier custody without extending CCR-2026-0017/0018. Owner: railiance-platform with the named secrets-engine and approval-engine operator consumers.

Prepare separate exact-reader admissions for existing version-1 paths: platform/workloads/secrets-engine/approval-client and platform/workloads/approval-engine/operator-client, field CLIENT_SECRET. Name each actual actor/placement, bounded authentication/reader policy, protected consumer delivery, cleanup/revocation and rollback, then obtain the required owner reviews for those concrete requests. No reseeding, rotation, shared reader, reuse of the sso verifier Secret, or implicit operator consume grant.

2026-09-09 preparation return: both exact-reader admissions are prepared as CCR-2026-0019 (secrets-engine) and CCR-2026-0020 (approval-engine-operator), with their exact-path read policies written and committed. Design: docs/credential-lane-designs/keycape-approval-client-side-readers.md. Both reuse existing version-1 custody; no reseed, rotation, shared reader or verifier Secret reuse. Both are in_flight and unapproved; nothing is applied.

Read-only survey findings that decided the two shapes. Namespace secrets-engine holds only ServiceAccount secrets-engine with no workload, and flex-auth/flex-auth-secrets-engine is that consumer's PDP, not the service; secrets-engine consumes the client secret through an operator-run CLI reading SECRETS_ENGINE_APPROVAL_CLIENT_SECRET_FILE (SECRETS-WP-0009-T03, revision 9eb07fd). So reader 1 is an attended operator-workstation OIDC lane, not an ESO lane. approval-engine has no namespace, workload or Service; its manifest is unapplied, and no owner source names who presents the operator client — approval-engine verifies these tokens and never holds them.

Unblock: reader 1 needs the exact NetKingdom/KeyCape group claim for the authorized operator, plus secrets-engine confirming the file mode and removal step; openbao.auth is declared missing rather than filled with a placeholder that would later read as a confirmed binding. Reader 2 needs its owner to name the presenting actor and placement, or to record that no client-side reader is wanted so the request is cancelled. Naming a reader for the widest approval scope without that decision is the failure this task exists to avoid.

Done when: each reader has a named actor and placement, a completed and reviewed auth binding, admitted delivery, and its owner approvals; positive and negative checks pass, including cross-path, wrong-identity and parent-list denial and operator consume denial; or the request is explicitly cancelled by its owner. Rotation stays a distinct version-guarded operation shared with CCR-2026-0017/0018.

Consumer input supplied 2026-09-09: secrets-engine now implements per-request secrets-engine-approval exchange from a protected temporary client-secret file, with exact approval-engine / tenant:platform / read-or-consume scope, no token file and no fallback. The pinned KeyCape image and actual Approval Engine source passed its disposable component exercise; only the PDP was a sequencing double. See secrets-engine/docs/approval-service-auth.md and the metadata receipt secrets-engine/docs/evidence/2026-09-09-approval-identity-exercise.json.

Routing check: warden route show keycape-secrets-engine-approval-client is unknown; generic openbao-api-key routes ownership only and is not a delegable lane. Do not advertise a working fetch command before this task supplies its own accepted native delivery return. Client-side admission is not ready for a new human decision until exact requests and contained execution/rollback checks are reviewable; the completed verifier reviews must not recur in that queue.

Done when: both separate consumer admissions are approved and implemented; actual consumer authentication/delivery succeeds; sibling/listing/wrong-reader and scope refusals plus reader expiry/revocation/cleanup are evidenced; version-1 custody and verifier availability remain intact. Return the source and metadata receipts to HFACT-WP-0001-T03, SECRETS-WP-0009-T03 and APPROVAL-WP-0002-T01/T05. Audit receiver/sender custody remains AUDIT-WP-0009-T09 and must not be folded into this client-identity grant.

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.