Document rapp-openbao compatibility handoff
This commit is contained in:
parent
963b1caceb
commit
09c6e41caa
6 changed files with 131 additions and 19 deletions
|
|
@ -10,10 +10,12 @@
|
|||
|
||||
---
|
||||
|
||||
Ownership note: the deployable OpenBao package surface documented here is the
|
||||
candidate for a future `rapp-openbao` repo. Platform custody, policy,
|
||||
credential lanes, delegated automation, and root-of-trust handling remain
|
||||
`railiance-platform` responsibilities even after that package extraction.
|
||||
Ownership note: the deployable OpenBao package surface now has a wave-1 home in
|
||||
`rapp-openbao`. Platform custody, policy, credential lanes, delegated
|
||||
automation, and root-of-trust handling remain `railiance-platform`
|
||||
responsibilities. Use `docs/rapp-openbao-compatibility-handoff.md` for the
|
||||
migration-window split between package-owned deploy/smoke surfaces and retained
|
||||
S3 bootstrap/governance work.
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# rapp-openbao Boundary
|
||||
|
||||
This document records the first-wave boundary for extracting a future
|
||||
This document records the first-wave boundary for extracting the wave-1
|
||||
`rapp-openbao` repo out of `railiance-platform`.
|
||||
|
||||
The rule is simple:
|
||||
|
|
@ -9,7 +9,7 @@ The rule is simple:
|
|||
- `railiance-platform` keeps secret custody, policy, lane governance, and
|
||||
platform-wide operator controls
|
||||
|
||||
## Package Assets For Future `rapp-openbao`
|
||||
## Package Assets For `rapp-openbao`
|
||||
|
||||
These files describe or implement the OpenBao workload package itself and are
|
||||
valid candidates for a dedicated wrapper repo.
|
||||
|
|
@ -58,7 +58,7 @@ These files and concerns stay in S3 even after a wrapper repo exists.
|
|||
|
||||
## First Move Set
|
||||
|
||||
The first repo-creation handoff for `rapp-openbao` should start with the least
|
||||
The initial repo-creation handoff for `rapp-openbao` started with the least
|
||||
coupled package assets:
|
||||
|
||||
- `helm/openbao-values.yaml`
|
||||
|
|
@ -75,6 +75,9 @@ coupled package assets:
|
|||
This first move set is enough to establish a package repo that can render,
|
||||
deploy, and verify OpenBao without inheriting platform lane governance.
|
||||
|
||||
The migration-window compatibility path between `railiance-platform` and
|
||||
`rapp-openbao` now lives in `docs/rapp-openbao-compatibility-handoff.md`.
|
||||
|
||||
## Resulting Rule
|
||||
|
||||
`rapp-openbao` may own how OpenBao is packaged, deployed, verified, and skinned
|
||||
|
|
|
|||
97
docs/rapp-openbao-compatibility-handoff.md
Normal file
97
docs/rapp-openbao-compatibility-handoff.md
Normal file
|
|
@ -0,0 +1,97 @@
|
|||
# `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.
|
||||
|
||||
## 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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue