| KV field | `REPOSITORY_RENAME_PREFLIGHT_SECRET` |
| Generation | At least 32 random bytes from a CSPRNG, encoded as 64 lowercase hex characters; generate in the approved protected writer, never print |
| Read policy | `workload-kv-read-state-hub-rename-preflight`: read only on the one exact data path |
| Kubernetes auth | Existing reviewed mount `kubernetes`; new role `state-hub-rename-preflight-eso` |
| Auth identity | Proposed dedicated service account `state-hub-preflight-eso` in `state-hub`; exact audience `openbao` subject to TokenReview/ESO compatibility proof |
| Token bounds | TTL/max/explicit max `15m`, no default or periodic policy; no write/admin policy |
| ESO scope | Namespace-scoped SecretStore `openbao-state-hub-rename-preflight`, dedicated ExternalSecret of the same workload scope |
| K8s target | Separate Secret `state-hub-rename-preflight`, field mapped to the exact environment name |
| Runtime binding | Explicit `secretKeyRef` in API Deployment only; required/non-optional |
Use the native OpenBao data GET for delivery. If the ESO version requires
metadata read, prove that need and review an exact metadata-path addition;
never grant parent list. ESO TokenRequest/RBAC and the OpenBao Kubernetes role
must agree on service account, namespace and audience. Do not change a shared
mount or borrow the existing Forge-derivation role, AppRole SecretID, admin PAT,
API token, webhook HMAC or database password.
The new Secret avoids having two controllers own `state-hub-env`. Its key must
not be added to ConfigMaps, general `envFrom`, Helm values containing plaintext,
migration Jobs, MCP containers, or the workstation/fallback Hub. Scope the
SecretStore to this namespace and restrict who can create ExternalSecrets or
TokenRequests for the delivery identity. Verify the API's explicit env entry
takes precedence and remove any stale same-name setting under its original
owner's control. Do not overwrite the whole existing shared Secret.
## Governed implementation
Create a proposed `workload-kv-read` CCR through the existing schema once exact
deployment bindings are confirmed. Keep the writer separate: the read CCR
does not authorize key generation or KV writes. The writer's one-time approved
scope is the exact data path with initial CAS zero or current-version CAS for
rotation. The API and ESO never get write access. Add coding-agent high-risk
boundary denies for data and metadata before provisioning.
Stage and review the policy, auth role, service account/RBAC, SecretStore,
ExternalSecret and API chart env entry together. The dedicated Secret should
retain its last value if the external source is unavailable; document the ESO
target ownership/deletion policy explicitly. A stalled ESO update does not
automatically invalidate a key already loaded in a running process. Require
green custody/version/rollout evidence before permitting rename operations.
## Activation and evidence
State Hub owner confirms the exact primary deployment, TTL and authorized
fixture preflight request; platform approves path/field and protected writer;
cluster owner accepts ESO bindings and API-only exposure. Record these owner
receipts and pinned source revisions before any live mutation.
Create a fresh key in protected custody, project it, verify SecretSynced and
safe version metadata, then roll every API replica. Check `/state/health` and
read-only rename preflight against an approved fixture. Any issued preflight
token remains in protected memory and must be redacted from evidence. Prove
