# 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: ```bash make openbao-dry-run make openbao-deploy make openbao-status ``` On Railiance01 directly: ```bash 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: ```bash 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 ```bash 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: ```bash 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: ```bash 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: ```bash kubectl exec -n openbao openbao-0 -- \ bao audit enable file file_path=/openbao/audit/openbao-audit.log ``` Enable the first KV v2 mount: ```bash 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: ```bash 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: ```bash 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 -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.