# rapp-openbao Boundary

This document records the first-wave boundary for extracting the wave-1
`rapp-openbao` repo out of `railiance-platform`.

The rule is simple:

- `rapp-openbao` owns the deployable OpenBao package surface
- `railiance-platform` keeps secret custody, policy, lane governance, and
  platform-wide operator controls

## Package Assets For `rapp-openbao`

These files describe or implement the OpenBao workload package itself and are
valid candidates for a dedicated wrapper repo.

| Path | Why it belongs with the package |
| --- | --- |
| `helm/openbao-values.yaml` | Helm values for the OpenBao workload |
| `helm/openbao-middleware.yaml` | OpenBao-specific ingress/middleware surface |
| `helm/openbao-ui-overlay-k8s.yaml` | OpenBao UI gateway Deployment/Service/Ingress manifest |
| `helm/openbao-ui-overlay/` | UI overlay assets and gateway config for the OpenBao service |
| `scripts/openbao-ui-overlay-apply.sh` | Applies package-owned UI overlay assets |
| `scripts/openbao-verify.sh` | Non-secret workload deployment verification |
| `scripts/openbao-verify-login-overlay.sh` | Verifies package-owned public UI overlay behavior |
| `docs/openbao-emergency-drill-evidence.example.json` | Example workload-specific emergency evidence format |
| `docs/openbao-restore-drill-evidence.example.json` | Example workload-specific restore evidence format |
| `scripts/openbao-validate-emergency-drill-evidence.sh` | Validates workload-specific emergency drill evidence |
| `scripts/openbao-validate-restore-evidence.sh` | Validates workload-specific restore drill evidence |

## Split-Before-Move Assets

These files mix package bring-up with retained S3 governance. They should be
split before a clean repo move.

| Path | Why it needs splitting |
| --- | --- |
| `docs/openbao.md` | Contains both package deployment/runbook material and retained platform custody/bootstrap policy |
| `scripts/openbao-apply-initial-config.sh` | Combines workload bootstrap with S3-owned `platform-admin` / `platform-readonly` policy loading and Kubernetes auth setup |
| `Makefile` target `openbao-configure-initial` | Thin wrapper around the mixed script above |
| `scripts/openbao-verify-authenticated.sh` | Verifies retained policy/auth/audit surfaces, not just package health |

## Retained `railiance-platform` Responsibilities

These files and concerns stay in S3 even after a wrapper repo exists.

| Path or family | Why it stays in S3 |
| --- | --- |
| `openbao/policies/platform-admin.hcl`, `openbao/policies/platform-readonly.hcl` | Platform operator and read-only policy surface |
| `docs/openbao-approved-automation-delegation.md` | Governance for approved metadata mutation under platform control |
| `openbao/policies/credential-change-*.hcl` and `scripts/openbao-apply-credential-change-appliers.py` | Delegated metadata-apply policy and role management |
| `docs/credential-change-approval.md`, `docs/credential-lane-lifecycle-runbook.md`, `docs/workload-kv-access-lanes.md`, `credential-change-requests/` | Source of truth for lane approval, lifecycle, and custody decisions |
| `openbao/policies/workload-kv-read-*.hcl` and `scripts/openbao-apply-workload-kv-lanes.sh` | Cross-workload runtime secret lane governance |
| `openbao/policies/external-secrets-*.hcl` and `scripts/openbao-apply-external-secrets-issue-core.sh` | Cross-workload External Secrets / ESO integration policy |
| `openbao/ssh/roles-spec.yaml`, `openbao/policies/warden-sign.hcl`, `scripts/openbao-apply-ssh-engine.sh`, `scripts/openbao-verify-ssh-engine.sh` | Platform SSH signing capability for ops-warden, not an OpenBao package concern |
| `docs/credential-broker.md`, `credential-grants/`, `scripts/credential.py`, `scripts/openbao-apply-token-grants.py`, `scripts/openbao-verify-token-grants.py`, `openbao/policies/credential-broker-*.hcl` | Platform credential-broker and token-grant governance |
| `scripts/forgejo-admin-pat-provision.sh` and other workload-lane provisioning helpers | Provision secrets for other workloads through OpenBao; not part of the OpenBao package itself |

## First Move Set

The initial repo-creation handoff for `rapp-openbao` started with the least
coupled package assets:

- `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`
- the `Makefile` targets `openbao-repo`, `openbao-dry-run`, `openbao-overlay-apply`,
  `openbao-deploy`, `openbao-status`, `openbao-verify`, and
  `openbao-verify-login-overlay`

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
for Railiance. It must not become the home for platform-admin policy, workload
KV lane policy, delegated metadata authority, credential grants, or human root
custody procedure.