coulomb/railiance-platform
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
railiance-platform/docs/rapp-openbao-compatibility-handoff.md
codex 617c292594
All checks were successful
CCR intake gate / gate (push) Successful in 14s
Details
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 2s
Details
Refuse OpenBao deploys from the retained copy and point operators to rapp-openbao. 
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
2026-11-03 11:18:44 +01:00

4.3 KiB
Raw Blame History

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.