railiance-platform/docs/openbao.md

OpenBao - Platform Secrets Service

Chart: openbao/openbao Chart version: 0.28.2 App version: v2.5.3 Namespace: openbao Managed by: railiance-platform (S3) Workplan: RAIL-PL-WP-0002 Initial target: Railiance01 (92.205.62.239)

---

Architecture

S5 workloads / operators
  -> openbao.openbao.svc.cluster.local:8200
       -> openbao-0
            -> integrated Raft storage on local-path PVC
            -> audit storage PVC mounted at /openbao/audit

• OpenBao is the canonical Railiance S3 secrets service.
• SOPS/age remains the Git-at-rest bootstrap mechanism.
• The first Railiance01 deployment is single-replica Raft, not true HA.
• Public ingress is disabled. Operators use kubectl exec or port-forwarding.
• TLS is disabled inside the pod listener for this internal-only bootstrap. Add cert-manager-backed internal TLS before exposing OpenBao beyond cluster-local traffic.

Deployment

The official OpenBao project recommends the Helm chart for Kubernetes deployments and warns to run Helm with --dry-run before install or upgrade.

From a host with kubeconfig access:

make openbao-dry-run
make openbao-deploy
make openbao-status

On Railiance01 directly:

cd ~/railiance-platform
sudo env KUBECONFIG=/etc/rancher/k3s/k3s.yaml make openbao-dry-run
sudo env KUBECONFIG=/etc/rancher/k3s/k3s.yaml make openbao-deploy
sudo env KUBECONFIG=/etc/rancher/k3s/k3s.yaml make openbao-status

If the repo is not present on Railiance01 yet, copy only the non-secret values file and run Helm directly:

scp helm/openbao-values.yaml tegwick@92.205.62.239:/tmp/openbao-values.yaml
ssh tegwick@92.205.62.239 \
  'sudo env KUBECONFIG=/etc/rancher/k3s/k3s.yaml helm upgrade --install openbao openbao/openbao \
     --version 0.28.2 \
     --namespace openbao \
     --create-namespace \
     -f /tmp/openbao-values.yaml \
     --dry-run'

Repeat without --dry-run to deploy.

Verification

kubectl get pods,svc,pvc -n openbao -o wide
kubectl exec -n openbao openbao-0 -- bao status

Expected immediately after install:

• openbao-0 is Running.
• openbao, openbao-active, openbao-internal, and openbao-ui services exist as cluster-internal services.
• data and audit PVCs are Bound.
• bao status reports Initialized: false and Sealed: true.

That state is intentional until the bootstrap ceremony is completed.

Bootstrap Ceremony

Do not initialize OpenBao in a casual shell session. Initialization emits the unseal keys and initial root token. Treat this as a break-glass event.

Recommended ceremony:

1. Confirm the Railiance01 backup posture first.

2. Prepare three human escrow recipients for unseal shares.

3. Run initialization once:

   kubectl exec -n openbao openbao-0 -- \
     bao operator init -key-shares=3 -key-threshold=2
   

4. Give each unseal share to its escrow owner through an out-of-band channel.

5. Unseal with two shares:

   kubectl exec -n openbao openbao-0 -- bao operator unseal
   

6. Log in with the initial root token only long enough to create durable admin auth, enable audit, and prepare policies.

7. Revoke or tightly escrow the initial root token.

Initial Configuration After Unseal

Enable file audit:

kubectl exec -n openbao openbao-0 -- \
  bao audit enable file file_path=/openbao/audit/openbao-audit.log

Enable the first KV v2 mount:

kubectl exec -n openbao openbao-0 -- \
  bao secrets enable -path=platform kv-v2

Kubernetes auth, database dynamic credentials, PKI, CSI, and External Secrets integration are follow-up tasks in RAIL-PL-WP-0002. Do not migrate live application secrets until those policies and restore drills are documented.

Artifact-Store Object Storage Handoff

artifact-store is the consumer-facing artifact preservation service for generated outputs, evidence packages, reports, logs, snapshots, exports, and release artifacts. It already has an S3-compatible backend with env:NAME and file:/mounted/path credential references, plus an artifactstore storage verify --backend s3 smoke path.

Railiance should avoid building a parallel object-storage client or credential vending flow in OpenBao. The ownership split is:

• railiance-platform / OpenBao owns bootstrap secret custody, policy, audit, break-glass access, and workload secret delivery.
• artifact-store owns artifact package manifests, the S3 backend, storage verification, and whether temporary credentials require backend refresh support or a sidecar/controller.
• net-kingdom owns the identity issuer and role-claim model if object storage adopts STS with AssumeRoleWithWebIdentity.

Initial static-credential bridge, before STS is proven:

1. Create a scoped object-store access key limited to the artifact-store bucket and prefix. Do not use object-store root credentials.

2. Store the key pair in OpenBao under a platform-owned path such as platform/object-storage/artifact-store.

3. Deliver the values to the artifact-store pod through CSI or External Secrets as mounted files.

4. Configure artifact-store with file references:

   export ARTIFACTSTORE_S3_ACCESS_KEY_REF=file:/run/secrets/artifactstore/s3-access-key
   export ARTIFACTSTORE_S3_SECRET_KEY_REF=file:/run/secrets/artifactstore/s3-secret-key
   

5. Verify from artifact-store:

   artifactstore storage verify --backend s3
   

STS credential vending remains linked to ARTIFACT-STORE-WP-0007 - MinIO Compatibility, MaxIO Fork Assessment, And STS Credential Vending. If that workstream chooses MinIO-compatible AssumeRoleWithWebIdentity, OpenBao should not become the identity provider by default. Use the NetKingdom OIDC issuer for workload/user identity, map object storage roles and policies there, and keep OpenBao responsible for bootstrap, break-glass, audit, and delivery of any controller configuration.

Current artifact-store configuration exposes access key and secret key refs, but no session-token ref. ARTIFACT-STORE-WP-0007-T004 must either add temporary-session-token support to the S3 backend or choose a sidecar/secret controller pattern that keeps refreshed credentials available through the existing env/file reference contract.

Upgrade And Rollback

1. Read the OpenBao chart release notes.
2. Update OPENBAO_CHART_VERSION in Makefile.
3. Run make openbao-dry-run.
4. Confirm current backup and audit log posture.
5. Run make openbao-deploy.
6. Run make openbao-status.

For rollback, run helm rollback openbao <REVISION> -n openbao on Railiance01 and re-check bao status.

Scaling To Three Nodes

When Railiance02 and Railiance03 join:

1. Move storage from local-path to distributed storage.
2. Set server.affinity back to anti-affinity.
3. Set server.ha.replicas: 3.
4. Re-enable a PodDisruptionBudget.
5. Run an unseal, failover, backup, and restore drill before migrating secrets.