3.8 KiB
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.yamlhelm/openbao-middleware.yamlhelm/openbao-ui-overlay-k8s.yamlhelm/openbao-ui-overlay/scripts/openbao-ui-overlay-apply.shscripts/openbao-verify.shscripts/openbao-verify-login-overlay.shscripts/openbao-validate-emergency-drill-evidence.shscripts/openbao-validate-restore-evidence.sh- the drill-evidence example JSON files
- the package-owned
Makefiletargets: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, andopenbao-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:
- update
rapp-openbaofirst; - refresh the compatibility copy in
railiance-platformonly when current operators or automation still depend on it; and - 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.mdsections covering init, unseal, custody, auth bootstrap, audit posture, and platform-owned policyscripts/openbao-apply-initial-config.shscripts/openbao-verify-authenticated.shscripts/openbao-apply-ssh-engine.shscripts/openbao-verify-ssh-engine.shscripts/openbao-apply-workload-kv-lanes.shscripts/openbao-apply-credential-change-appliers.pyscripts/openbao-apply-token-grants.py- the matching
Makefiletargets: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/, andcredential-grants/
Operator Migration Path
Operators can move without a flag day:
- Use
rapp-openbaofor package deploy, overlay, smoke, and package-owned drill-evidence work. - Continue using
railiance-platformfor attended bootstrap, authenticated verification, and policy/governance flows. - 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 inrapp-openbaofirst. - 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.