coulomb/the-custodian
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Clarify core hub staging credential route

Browse Source
This commit is contained in:
Bernd Worsch
2026-06-30 10:20:23 +02:00
parent cb7fd7b19d
commit 1f9ef92a66
4 changed files with 37 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
docs/credential-custody-unblock-board.md
View File

@@ -1,6 +1,7 @@
# Credential Custody Unblock Board
Created: 2026-06-27
Updated: 2026-06-30
Owner: the-custodian coordination; credential owners remain with their owning repos.
## Purpose
@@ -55,7 +56,8 @@ Current read:
| Gate family | Posture/maturity read |
| --- | --- |
| Inter-Hub / ops-hub runtime keys | Production real-value gate; implementation can proceed with route evidence, but live smoke waits on OpenBao/operator custody. |
| Inter-Hub / ops-hub runtime keys | Legacy/fallback production real-value gate; implementation can proceed with route evidence, but live smoke waits on OpenBao/operator custody. |
| Core Hub deployed smoke/runtime token | Preferred replacement gate: `CORE_HUB_BASE_URL` is endpoint routing, operator/runtime token custody routes to `openbao-api-key`, and activity-core widget mapping belongs to Core Hub/activity-core. ops-warden does not mint or store this token. |
| activity-core to issue-core | Production service credential gate; the blocker is `ISSUE_CORE_API_KEY` injection/evidence, not repo-side contract work. |
| OpenBao unseal / issuer profile | M3-style operator ceremony. The narrow `warden-sign` lane is verified/banked; broader issuer/profile work remains separate. |
| ops-warden policy gate / warden-sign | Verified and banked: `SECRETS-WP-0004` and `FLEX-WP-0007` are finished, with `decision:032b096c433ad80c`, `ttl_out_of_bounds`, backend `vault`, and no secret material recorded. |
@@ -65,6 +67,7 @@ Current read:
| Gate | Blocking work | Owner and route | Expected execution host | Non-secret evidence | Fallback decision | Next action | Status |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Core Hub deployed evidence and activity-core sink | `CUST-WP-0025-T16`, `CORE-WP-0004-T03/T04`, feeds `CUST-WP-0025-T17` | `openbao-api-key` for operator/runtime token custody; `ops-bridge-tunnel` if the staging URL is private; Core Hub/activity-core for widget mapping | Core Hub staging runtime, operator workstation, or trusted cluster job | deployed-smoke run id, hub/manifest/API-consumer ids, key prefix only, widget/event ids, counts, readiness and containment booleans | Keep Inter-Hub as legacy/fallback until Core Hub evidence exists or explicit supersede decision. | Provide `CORE_HUB_BASE_URL`, approved token custody, activity-core widget id/mapping, then run deployed smoke plus sink smoke. | Waiting on staging/custody handoff |
| Inter-Hub ops-hub bootstrap | `CUST-WP-0049-T06`, unblocks `CUST-WP-0047-T05` | `inter-hub-bootstrap-ssh` for the envelope; `openbao-api-key` for operator/runtime key custody; `ssh-cert-host-access` only for cert signing if remote execution is used | Local workstation with `IHUB_OPERATOR_KEY_FILE`, or trusted host with railiance-infra force-command wrapper | Hub id, manifest id, widget count, runtime key prefix only, bootstrap smoke result, State Hub progress id | Prefer API helper. Use deployment-side migration/bootstrap only by explicit operator approval. Manual SQL remains last-resort and must be recorded as an exception. | Operator materializes Inter-Hub operator key through approved custody, runs the ops-hub helper, stores generated runtime key outside Git, removes temp files. | Ready for operator handoff |
| Ops-hub runtime evidence key | `IHUB-WP-0022-T04`, then `IHUB-WP-0022-T07` | `openbao-api-key` owned by `railiance-platform` / OpenBao | Operator workstation, OpenBao UI/CLI session, or trusted cluster job; not a Codex-visible shell with printed values | OpenBao path/version or populated key count only, token exchange HTTP status, evidence submission smoke id | Attended one-time key file is acceptable only long enough to store in OpenBao and remove; no chat or State Hub transfer. | Store/provide `OPS_HUB_KEY` via OpenBao path, then run Inter-Hub submission smoke. | Waiting on operator custody |
| OpenBao unseal and token automation | `NET-WP-0020`, related OpenBao token-grant and policy-gate blockers | `openbao-api-key` for OpenBao issuer/token paths; `railiance-infra-principals` for host policy; `ssh-cert-host-access` for cert signing; `key-cape-oidc-login` for login/MFA | OpenBao operator terminal, cluster-admin context, or trusted railiance-infra deployment path | Policy names, role names, token accessor only, decision ids, allow/deny smoke result | Keep attended ceremony path until auto-unseal/profile is explicitly approved. Do not invent `warden secret` or paste `VAULT_TOKEN`. | Broader custody profile remains open; do not treat the completed `warden-sign` lane as a general OpenBao credential helper. | Needs operator design/approval |
@@ -85,10 +88,11 @@ uv run warden route show ops-bridge-tunnel --json
## Pickup Order
1. Inter-Hub ops-hub bootstrap, because it unlocks both the now-view and the
activity-core evidence lane.
2. Ops-hub runtime evidence key, because it is the immediate smoke gate after
bootstrap.
1. Core Hub deployed evidence and activity-core sink smoke, because this is
the preferred replacement proof for ops-hub evidence and can supersede
legacy Inter-Hub waits once real staging evidence exists.
2. Keep Inter-Hub ops-hub bootstrap and runtime keys as legacy/fallback only
unless the operator explicitly chooses rollback or compatibility proof.
3. OpenBao custody profile, because several credential-helper and policy-gate
blockers collapse once a narrow issuer path exists.
4. Forgejo production decisions, because those require human design approval