coulomb/secrets-engine
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
secrets-engine/docs/keycape-isolated-recovery-selector.md
tegwick c59bbf568c
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details
feat(recovery): prepare owner-bound offline continuity preflight 
Assistant: codex
Assistant-Model: gpt-6.1-sol
Assistant-Session: 01a1468b-63fa-7710-85dc-8f2e16b3ebfa
2026-10-17 01:03:36 +02:00

2.4 KiB
Raw Permalink Blame History

KeyCape original service recovery selector

Source-owner disposition, 2026-10-17, limited to secrets-engine's current consumer contract. Current src/secrets_engine/service_auth.py fixes client/audience secrets-engine-openbao, subject service:secrets-engine, tenant tenant:platform, role secrets-engine and exact openbao:login scope. The NetKingdom producer binds KEYCAPE_SECRETS_ENGINE_OPENBAO_CLIENT_SECRET; original KeyCape native evidence uses openbao:admin as the denied-scope case. This selector matches the current consumer source. This disposition is not native assent or a credential grant.

SECRETS-WP-0012 finished on historical attended custody/probe evidence and stays finished. SECRETS-WP-0008-T06 retains functional steady-state adoption and scoped backend entitlement. SECRETS-WP-0013 retains task-scoped backend execution. The new SECRETS-WP-0015 covers only this original archive/isolated consumer preparation and later accepted continuity proof; those existing gates are not duplicated.

The current consumer profile forbids a client-secret file and requires its attended in-memory OpenBao source. That source depends on ordinary KeyCape OIDC and OpenBao availability. The isolated issuer's native checker can consume its original archive-delivered issuer binding without a provider login, but that does not prove the secrets-engine consumer path works during an OpenBao/issuer outage. Do not bypass the no-file/source contract, retrieve a live credential, redirect a production consumer or invoke probe-openbao to fill this recovery gap. An exact owner-reviewed outage-compatible proof/custody plan remains required.

Offline public preflight, after integration of reviewed source:

python3 tools/check-keycape-recovery-selector.py --selector docs/keycape-recovery-selector.json --source-sha256 sha256:c0ade429edf452ad17f05d690b7ebef091db7f1a42b5ac350f1e40955c8586c0

Use the exact hash in the owner packet, not a digest inferred at invocation from an unreviewed file. The tool parses source constants with AST and never imports the credential/backend module or calls the network. It requires all eight public selector fields, exact source hash and unambiguous bounded JSON. Successful output means source correspondence only. Original archived presence/secret binding, actual TLS trust, native claim negatives and selected consumer continuity remain separately evidenced. Missing/changed bindings refuse before any custody request.