208 lines
6.8 KiB
Markdown
208 lines
6.8 KiB
Markdown
# 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 <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.
|