railiance-platform/docs/evidence/2026-09-13-keycape-factor-custody.md

KeyCape factor credential custody — 2026-09-13

User-authorized attended setup is live under RPF-WP-0040 / CCR-2026-0023. The operator authenticated through the contained OpenBao login lane. No credential value was included in source, receipts, chat or ordinary logs.

Dedicated privacyIDEA identity keycape-factor-reader has tokenlist permission for coulomb. Its password is in a separate OpenBao issuer path; KeyCape receives only a provider-issued, expiring JWT via External Secrets. Explicit fallback policy preserves existing administrators' prior rights and excludes this service identity. The service cannot read provider administration policy.

Live checks passed:

• Exact OpenBao policy/role readback, audience and service-account bindings.
• Provider-issued credential, cross-user factor visibility, and the actual KeyCape user + realm + active=True lookup shape.
• Wrong service account rejected; issuer password and sibling KV reads denied.
• ExternalSecret sso/keycape-factor-read: Ready=True / SecretSynced.
• Initial renewal Job published KV version 2 and revoked its OpenBao session. A second Job published version 3; the existing mounted file received the replacement and provider lookup accepted it without a pod restart.
• KeyCape config activation passed server dry-run and UID/resource-version CAS; readback confirmed all other Secret data and configuration bytes preserved. Deployment rolled out successfully with the existing image sha256:c9eb584d60efecfe00e1745a7e8cd3ebb4ae0f94faa715ef9594cd58a5dcebb6.
• Fourteen offline tests cover identity/expiry/status rejection, scope boundaries, failed-provider preservation, CAS failure, session-cleanup failure, retry, ambiguous config rejection and byte-preserving activation.

Runtime source: manifests/keycape-factor-custody.yaml; renewal every ten minutes, ESO refresh every minute. Renewal runs as non-root with an immutable ConfigMap, digest-pinned image, dedicated service account and restricted network policy. The reader has no issuer-password permission; the renewer cannot write that password. OpenBao sessions last at most fifteen minutes (ESO) or five minutes (renewer). Successful renewal workers revoke their sessions explicitly.

Repeat: make keycape-factor-tests and make keycape-factor-live-acceptance. Exact-commit CI is .forgejo/workflows/keycape-factor-acceptance.yaml. The first proof Job was keycape-factor-delivery-acceptance; its short-lived reader session expires by its fifteen-minute maximum TTL. The final reusable proof also revokes its session; its result is recorded below after execution.

Limits: this establishes credential custody, renewal and native delivery. Genuine provider JWT expiry/revocation drills remain RPF-WP-0040-T04; renewing a JWT does not revoke its predecessor. Optional-after-enrollment policy remains unchanged. OTP onboarding, lost-factor recovery and their complete platform-admin browser journeys remain KEY-WP-0035 / USER-WP-0030. Historical resolver incident NK-WP-0033 is not closed by this new service lane.

Final reusable proof passed: keycape-factor-proof-0c4a6929. All eight checks were true: wrong-SA rejection, issuer-password denial, sibling-secret denial, mounted-token/custody equality, KeyCape per-user lookup, provider administration denial, renewed projection acceptance, and explicit reader-session revocation. KeyCape remained Ready 1/1 at deployment generation 46. CCR validation passed.

P05 acceptance closure — 2026-09-13

RPF-WP-0040-T04 is complete. Actual installed-provider isolated fixture provider-p05-contract-01 verifies expiry, fresh-session recovery, expired predecessor denial and policy permission withdrawal/recovery. Native proof keycape-factor-proof-91ea82cd repeated all eight checks successfully, including mounted rotation after renewal Job keycape-factor-rotate-91ea82cd and explicit proof-session revocation. CronJob retains failed Jobs (limit 3), and ESO reports Ready/SecretSynced. Provider and credential failure/recovery are covered by KeyCape's Go adapter suite. See user-engine's P05 evidence for exact boundaries. The preceding "remaining T04" statements are historical and superseded here. Existing NK-WP-0033 and KEY-WP-0035 retain resolver/policy residual ownership.