617c292594
openbao-deploy and openbao-overlay-apply now exit 2 without calling kubectl or helm. The two copies had drifted in both directions, so a deploy from either one reverted the other's changes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 236506@bnt-lap001 Assistant-Session: 09087018-91e1-48c5-ab2f-acfbb62c92e4
107 lines
4.3 KiB
Markdown
107 lines
4.3 KiB
Markdown
# `rapp-openbao` Compatibility Handoff
|
|
|
|
## Purpose
|
|
|
|
Define the migration-window handoff between `railiance-platform` and
|
|
`rapp-openbao` for the deployable OpenBao package surface.
|
|
|
|
Wave 1 makes `rapp-openbao` the durable owner of the OpenBao package contract.
|
|
`railiance-platform` remains the S3 owner of custody, policy, credential-lane
|
|
governance, and root-of-trust handling. During the migration window,
|
|
`railiance-platform` keeps a thin compatibility surface so current operators do
|
|
not need a flag day.
|
|
|
|
## Canonical Package Owner
|
|
|
|
Use `rapp-openbao` as the canonical home for these package-owned assets and
|
|
behaviors:
|
|
|
|
- `helm/openbao-values.yaml`
|
|
- `helm/openbao-middleware.yaml`
|
|
- `helm/openbao-ui-overlay-k8s.yaml`
|
|
- `helm/openbao-ui-overlay/`
|
|
- `scripts/openbao-ui-overlay-apply.sh`
|
|
- `scripts/openbao-verify.sh`
|
|
- `scripts/openbao-verify-login-overlay.sh`
|
|
- `scripts/openbao-validate-emergency-drill-evidence.sh`
|
|
- `scripts/openbao-validate-restore-evidence.sh`
|
|
- the drill-evidence example JSON files
|
|
- the package-owned `Makefile` targets:
|
|
`openbao-repo`, `openbao-dry-run`, `openbao-overlay-apply`,
|
|
`openbao-deploy`, `openbao-status`, `openbao-verify`,
|
|
`openbao-verify-post-unseal`, `openbao-verify-login-overlay`,
|
|
`openbao-validate-restore-evidence`, and
|
|
`openbao-validate-emergency-evidence`
|
|
|
|
New behavior, docs, and fixes for that deploy/overlay/smoke surface should land
|
|
in `rapp-openbao` first.
|
|
|
|
## Platform-Side Compatibility Surface
|
|
|
|
During the migration window, `railiance-platform` may still expose the same
|
|
package-owned `Makefile` targets and keep compatibility copies of the
|
|
package-owned files listed above.
|
|
|
|
Those copies are for operator continuity only. They are not the long-term
|
|
source of truth.
|
|
|
|
If package-owned behavior changes:
|
|
|
|
1. update `rapp-openbao` first;
|
|
2. refresh the compatibility copy in `railiance-platform` only when current
|
|
operators or automation still depend on it; and
|
|
3. avoid evolving the platform copy independently.
|
|
|
|
Since 2026-11-03 the write targets `openbao-deploy` and
|
|
`openbao-overlay-apply` in `railiance-platform` refuse and point to
|
|
`rapp-openbao`. Two changes had landed only in the platform copy: the
|
|
RPF-WP-0057 workload-role login choice and the RPF-WP-0063 gateway CPU
|
|
request. Meanwhile the package copy gained the RAPP-OPENBAO-WP-0003
|
|
break-glass listener. A package deploy then reverted the live UI, and a
|
|
platform deploy would have removed the listener. Both changes are now in
|
|
`rapp-openbao` (RAPP-OPENBAO-WP-ADHOC-2026-11-03). Read-only targets, such as
|
|
`openbao-verify-login-overlay`, still run here.
|
|
|
|
## What Stays In `railiance-platform`
|
|
|
|
The handoff does not expand the package boundary.
|
|
|
|
Still retained in `railiance-platform` as S3 ownership:
|
|
|
|
- `docs/openbao.md` sections covering init, unseal, custody, auth bootstrap,
|
|
audit posture, and platform-owned policy
|
|
- `scripts/openbao-apply-initial-config.sh`
|
|
- `scripts/openbao-verify-authenticated.sh`
|
|
- `scripts/openbao-apply-ssh-engine.sh`
|
|
- `scripts/openbao-verify-ssh-engine.sh`
|
|
- `scripts/openbao-apply-workload-kv-lanes.sh`
|
|
- `scripts/openbao-apply-credential-change-appliers.py`
|
|
- `scripts/openbao-apply-token-grants.py`
|
|
- the matching `Makefile` targets:
|
|
`openbao-configure-initial`, `openbao-configure-ssh`,
|
|
`openbao-verify-ssh`, `openbao-verify-authenticated`,
|
|
`openbao-configure-workload-kv-lanes`,
|
|
`openbao-configure-credential-change-appliers`,
|
|
`openbao-configure-token-grants`, and related verification targets
|
|
- platform policy, credential-grant, and delegated-metadata source under
|
|
`openbao/policies/`, `credential-change-requests/`, and `credential-grants/`
|
|
|
|
## Operator Migration Path
|
|
|
|
Operators can move without a flag day:
|
|
|
|
1. Use `rapp-openbao` for package deploy, overlay, smoke, and package-owned
|
|
drill-evidence work.
|
|
2. Continue using `railiance-platform` for attended bootstrap, authenticated
|
|
verification, and policy/governance flows.
|
|
3. If existing automation still calls the package-owned OpenBao targets from
|
|
`railiance-platform`, it may keep doing so during the migration window, but
|
|
canonical fixes still land in `rapp-openbao` first.
|
|
4. Split mixed docs and scripts before removing the platform compatibility
|
|
copies.
|
|
|
|
## Exit Condition
|
|
|
|
The migration window can end once current operators and automation no longer
|
|
depend on `railiance-platform` copies of package-owned OpenBao files or
|
|
targets, and the remaining mixed material has been split cleanly.
|