tegwick
0617923ff1
Assistant: codex Assistant-Model: gpt-5.6-sol Assistant-Session: 01a0217e-8c4c-7383-be6b-f50a6e485306
252 lines
10 KiB
Markdown
252 lines
10 KiB
Markdown
---
|
|
id: SECRETS-WP-0006
|
|
type: workplan
|
|
title: "Adopt concrete OpenBao credential lanes from ops-warden"
|
|
domain: infotech
|
|
repo: secrets-engine
|
|
status: active
|
|
owner: codex
|
|
topic_slug: custodian
|
|
created: "2026-08-21"
|
|
updated: "2026-08-21"
|
|
---
|
|
|
|
# SECRETS-WP-0006 - Adopt concrete OpenBao credential lanes from ops-warden
|
|
|
|
## Goal
|
|
|
|
Move concrete, OpenBao-backed credential workflows from ops-warden's interim
|
|
proxy into the secrets-engine catalog and operating surface without moving
|
|
secret custody out of OpenBao or misassigning generic routing and identity
|
|
capabilities to this repo.
|
|
|
|
The intake originates in ops-warden message
|
|
`cbd312f8-347e-44cc-933b-9712e2036646` after earlier requests on 2026-08-11 and
|
|
2026-08-15.
|
|
|
|
## Scope decision
|
|
|
|
Accept these concrete OpenBao KV lanes for catalog admission and staged
|
|
operation:
|
|
|
|
- `issue-core-ingestion-api-key`;
|
|
- `reuse-surface-hub-write-token`;
|
|
- `openrouter-llm-connect`;
|
|
- `forgejo-admin-api-token`;
|
|
- `email-connect-transactional`.
|
|
|
|
Do not create catalog entries for these generic or non-owned routes:
|
|
|
|
- `openbao-api-key` remains a generic credential-routing template. Concrete
|
|
workload credentials beneath it may become catalog lanes, but the template is
|
|
not itself a secret lane.
|
|
- `key-cape-oidc-login` remains owned by key-cape/Keycloak. secrets-engine may
|
|
consume OIDC identity for OpenBao authentication, but it does not own login,
|
|
MFA, or identity-token issuance.
|
|
|
|
The current implementation is generic at the catalog level for KV
|
|
`mount`/`path`/`fields`, and `secrets-engine exec` supports `exec-env` plus the
|
|
npm-specific `npm-config` adapter. The remaining delivery-mode names are not all
|
|
exec adapters: `read-check` is verification, `approle-login` is auth-capability
|
|
handoff, and `exec-file`/`wrapped` are not yet implemented by `exec`.
|
|
|
|
## Design constraints
|
|
|
|
- OpenBao remains the custody, policy, lease, and audit backend.
|
|
- No raw value, token, password, wrapped token, AppRole material, or accessor is
|
|
written to Git, State Hub, chat, prompts, workplans, or normal logs.
|
|
- Catalog adoption does not by itself authorize production mutation or value
|
|
access. Each production lane needs a resolved approval and a reviewed live
|
|
apply/verification plan.
|
|
- Existing workload delivery must not be displaced. ESO/Kubernetes delivery and
|
|
provider-side rotation remain owned by their current runtime and provider
|
|
owners until an explicit migration is approved.
|
|
- High-risk lanes must retain exact consumer, field, rotation-owner, denial, and
|
|
revocation metadata.
|
|
- The production stage role currently manages owner-scoped paths on the
|
|
`secret` mount, while these lanes use the existing `platform` mount. Admission
|
|
must not silently broaden the stage role or attempt to create that mount.
|
|
|
|
## Confirm capability and ownership with ops-warden
|
|
|
|
```task
|
|
id: SECRETS-WP-0006-T01
|
|
status: done
|
|
priority: high
|
|
```
|
|
|
|
Completed 2026-08-21. Replied in the existing thread with State Hub message
|
|
`7fb0c2ce-be41-4a1d-95b0-e2cdd97d5718`, marked the inbound message read, and
|
|
recorded decision `ae676382-1826-4e04-aa4e-bb77990c7a0d`. The reply accepted
|
|
the five concrete KV lanes, declined the generic OpenBao route and key-cape
|
|
login route, corrected the six-delivery-mode interpretation, and kept interim
|
|
proxies in place pending per-lane verification.
|
|
|
|
Reply in the existing State Hub thread with the accepted five-lane scope, the
|
|
two declined generic/non-owned routes, and the delivery-mode correction. Accept
|
|
ops-warden's offer of a PR-shaped non-secret metadata contribution for the five
|
|
concrete lanes.
|
|
|
|
Done when the reply is posted, the inbound message is marked read, and this
|
|
decision is recorded as non-secret State Hub evidence.
|
|
|
|
## Define admission contract for existing production lanes
|
|
|
|
```task
|
|
id: SECRETS-WP-0006-T02
|
|
status: done
|
|
priority: high
|
|
```
|
|
|
|
Completed 2026-08-21. Added explicit `mount_management`, `delivery_auth`, and
|
|
`workload_delivery` semantics, with the operating contract documented in
|
|
`docs/catalog-admission.md`. Existing mounts and externally managed delivery
|
|
auth now render non-mutating checks; apply cannot create or rewrite them.
|
|
Existing workload delivery remains independent metadata, while an optional
|
|
engine-managed AppRole is a separate approval-gated native delivery surface.
|
|
|
|
Define how a catalog entry represents a lane whose KV mount already exists and
|
|
whose workload delivery is ESO/Kubernetes rather than a secrets-engine-created
|
|
AppRole. Separate these concepts where needed:
|
|
|
|
- existing-mount versus engine-managed mount;
|
|
- workload delivery versus agent/operator exec delivery;
|
|
- catalog/verification metadata versus engine-managed consumer auth;
|
|
- provider-side rotation owner versus OpenBao value update workflow.
|
|
|
|
Acceptance:
|
|
|
|
- Dry-run cannot propose creating or broadening the shared `platform` mount.
|
|
- A lane can retain its existing workload auth/delivery while optionally
|
|
exposing an approved exec-time adapter.
|
|
- The production stage role is not broadened by implication.
|
|
|
|
## Review and import the five catalog entries
|
|
|
|
```task
|
|
id: SECRETS-WP-0006-T03
|
|
status: done
|
|
priority: high
|
|
```
|
|
|
|
Completed 2026-08-21. The offered contribution did not arrive, so drafted all
|
|
five entries from ops-warden playbooks and the authoritative railiance-platform
|
|
CCRs, then requested line-by-line review in message
|
|
`ceace632-2332-46d8-a2b3-1714fbfa7e2c`. Ops-warden confirmed the mounts, paths,
|
|
field sets, CCR references, consumers, lifecycle owners, existing workload
|
|
delivery, proposed exact-path AppRole surface, both route rejections, and the
|
|
delivery-mode correction in messages `26df37c5-2756-49b8-8f9c-c1bb2bab1b4b`
|
|
and `3f875d90-6f88-4f44-961b-6f6fbd15b01d`. The follow-up retracted the only
|
|
apparent metadata concern: `REUSE_SURFACE_FORGEJO_WEBHOOK_SECRET` is explicitly
|
|
present in CCR-2026-0005, so both reuse-surface and issue-core remain correctly
|
|
classified `high`. Interim proxy ownership remains unchanged until T05.
|
|
|
|
Review ops-warden's proposed entries line by line against the schema, canonical
|
|
security boundary, live route metadata, and owning workload documentation.
|
|
Correct field lists, mount/path, consumers, delivery modes, approval references,
|
|
rotation owners, and negative checks before merging.
|
|
|
|
Acceptance:
|
|
|
|
- All five files contain non-secret metadata only.
|
|
- Generic `openbao-api-key` and `key-cape-oidc-login` entries are absent.
|
|
- Each entry names an exact lane rather than a provider-wide wildcard.
|
|
- Each high-risk lane has explicit rotation and deactivation expectations.
|
|
|
|
## Implement guards and offline verification
|
|
|
|
```task
|
|
id: SECRETS-WP-0006-T04
|
|
status: done
|
|
priority: high
|
|
```
|
|
|
|
Completed 2026-08-21: implemented non-mutating existing-mount/auth planning and
|
|
apply behavior, workload-delivery validation, exact field guards for exec and
|
|
verification, safe policy/role overrides, route guidance, and focused tests.
|
|
All five admitted entries load and render `kv-mount-check` plus an exact-path
|
|
policy and bounded AppRole plan. Generic/wildcard entries and undeclared fields
|
|
are negatively covered. Privileged provision, verify, exec, handoff, and live
|
|
revoke operations now fail closed without a resolved approval. Full verification
|
|
passes 82 tests.
|
|
|
|
Implement only the schema/planning/delivery changes required by the admitted
|
|
entries. Add tests for shared existing mounts, auth/delivery separation,
|
|
multi-field selection, exact exec-env injection, and rejection of wildcard or
|
|
generic provider-wide entries.
|
|
|
|
Acceptance:
|
|
|
|
- The complete catalog loads and validates.
|
|
- Each admitted lane renders a non-mutating guarded plan.
|
|
- Negative tests prove no wildcard path, broad policy, undeclared field, or
|
|
unsupported delivery mode is accepted.
|
|
- `uv run pytest` and `git diff --check` pass.
|
|
|
|
## Stage live apply and verification
|
|
|
|
```task
|
|
id: SECRETS-WP-0006-T05
|
|
status: wait
|
|
priority: high
|
|
```
|
|
|
|
Readiness update 2026-08-21: rendered non-mutating production dry-runs for all
|
|
five lanes. Every plan checks the externally managed `platform` mount without
|
|
mutation, writes one exact-path read policy, and proposes the reviewed bounded
|
|
AppRole (15-minute token TTL, 30-minute maximum TTL, 15-minute single-use
|
|
Secret ID, and eight token uses). OpenBao is reachable and unsealed, but route
|
|
status remains `ready: false`: the original CCR references approve the existing
|
|
workload lanes and are not resolvable State Hub approvals for the new native
|
|
AppRoles. This session also has no production OpenBao token or bootstrap file.
|
|
Requested per-lane approval references and scoped attended/apply authority from
|
|
railiance-platform in message `3db3da86-2f3f-4301-8be6-74b507ea66a0`. No value
|
|
was read and no OpenBao mutation was attempted.
|
|
|
|
Hardening dependency 2026-08-23: `SECRETS-WP-0007` now owns the engine-level
|
|
provisioning, lifecycle, approval-binding, delivery-session, verification, and
|
|
evidence gaps found during scope assessment. T05 must not provision or revoke
|
|
the existing shared paths through the current commands. Native live adoption
|
|
resumes through `SECRETS-WP-0007-T07` after its T01-T06 safety gates; this task
|
|
continues to own the per-lane production evidence and acceptance outcome.
|
|
|
|
For each lane, obtain the required decision/operator approval before any live
|
|
OpenBao policy, auth-role, provisioning, rotation, or delivery change. Start
|
|
with metadata/capability-safe checks and preserve the current ops-warden proxy
|
|
until native positive and negative verification succeeds.
|
|
|
|
Acceptance per lane:
|
|
|
|
- Approval is resolved and linked.
|
|
- Existing workload delivery remains healthy.
|
|
- Positive access and unrelated-consumer denial are proven without reading a
|
|
value into evidence.
|
|
- Rollback/revocation steps are recorded.
|
|
|
|
## Reconcile routing ownership and retire interim proxies
|
|
|
|
```task
|
|
id: SECRETS-WP-0006-T06
|
|
status: wait
|
|
priority: medium
|
|
```
|
|
|
|
After a lane is natively ready, update the ops-warden delegation register and
|
|
safe next action for that lane. Retire interim proxy operation lane by lane,
|
|
not as a seven-lane batch.
|
|
|
|
Acceptance:
|
|
|
|
- Native readiness is evidenced before the proxy is retired.
|
|
- ops-warden remains the routing front door and does not vend non-SSH secrets.
|
|
- The generic OpenBao route and key-cape login route retain their correct
|
|
owners.
|
|
|
|
## Exit criteria
|
|
|
|
- The five concrete OpenBao lanes have reviewed catalog entries and guarded
|
|
offline plans.
|
|
- Live ownership moves only for lanes that pass approved positive/negative
|
|
verification.
|
|
- The two generic/non-owned routes are not mislabeled as secrets-engine lanes.
|
|
- No secret material is recorded in repository or coordination evidence.
|