225 lines
8.0 KiB
Markdown
225 lines
8.0 KiB
Markdown
---
|
|
id: RAIL-PL-WP-0002
|
|
type: workplan
|
|
title: "OpenBao Platform Secrets Service"
|
|
domain: railiance
|
|
repo: railiance-platform
|
|
status: active
|
|
owner: codex
|
|
topic_slug: railiance
|
|
planning_priority: high
|
|
planning_order: 2
|
|
created: "2026-05-17"
|
|
updated: "2026-05-17"
|
|
depends_on:
|
|
- RAIL-PL-WP-0001
|
|
state_hub_workstream_id: "fd1c045a-01d4-43be-980f-acbda6c64e6c"
|
|
---
|
|
|
|
# RAIL-PL-WP-0002 - OpenBao Platform Secrets Service
|
|
|
|
## Goal
|
|
|
|
Establish OpenBao as the canonical Railiance S3 platform secrets service,
|
|
or define a controlled transition path from existing HashiCorp Vault
|
|
assumptions to OpenBao.
|
|
|
|
This workplan belongs in `railiance-platform` because S3 owns shared
|
|
platform services: secret management, identity integration, object
|
|
storage, backups, and other services consumed by S5 applications.
|
|
|
|
## Context
|
|
|
|
OpenBao is an open-source, Linux Foundation-governed fork of Vault for
|
|
managing, storing, and distributing secrets, certificates, and keys.
|
|
The official OpenBao documentation includes Kubernetes deployment via
|
|
Helm, CSI provider support, dynamic database secrets, Kubernetes service
|
|
account token generation, and lease/revocation semantics.
|
|
|
|
Current local architecture references still mention HashiCorp Vault in
|
|
several places, especially credential bootstrap and ops-warden's Vault
|
|
SSH backend. Railiance also uses SOPS/age for Git-at-rest secrets. The
|
|
platform needs an explicit decision and migration path so "Vault" does
|
|
not remain an accidental brand-specific dependency where "secrets
|
|
manager" is what we really mean.
|
|
|
|
## Scope
|
|
|
|
In scope:
|
|
|
|
- decide whether OpenBao is the canonical Railiance platform secrets
|
|
service
|
|
- define deployment topology for OpenBao on the Railiance Kubernetes
|
|
platform
|
|
- define auth methods for workloads, operators, and automations
|
|
- define secret engines for KV, database dynamic secrets, Kubernetes
|
|
tokens, PKI/certificates, and future object-storage credential
|
|
vending integrations
|
|
- define CSI provider and/or External Secrets Operator integration
|
|
- define unseal, backup, restore, break-glass, audit, and monitoring
|
|
procedures
|
|
- identify NetKingdom documentation and workplan updates needed to
|
|
replace HashiCorp Vault-specific language with OpenBao-first language
|
|
|
|
Out of scope:
|
|
|
|
- replacing SOPS/age for Git-at-rest bootstrap secrets
|
|
- changing S1/S2 cluster runtime configuration without coordination
|
|
- rewriting ops-warden's SSH certificate backend in this workplan
|
|
- implementing application-specific secrets in S5
|
|
|
|
## Tasks
|
|
|
|
### T01 - OpenBao Decision And Migration Inventory
|
|
|
|
```task
|
|
id: RAIL-PL-WP-0002-T01
|
|
status: done
|
|
priority: high
|
|
state_hub_task_id: "e997ffe0-6b61-4242-b585-f271e9b75e99"
|
|
```
|
|
|
|
Inventory current HashiCorp Vault assumptions across NetKingdom,
|
|
ops-warden, Railiance, and application runbooks. Decide whether
|
|
Railiance standardizes on OpenBao, keeps Vault-compatible abstraction
|
|
language, or supports both for a transition period.
|
|
|
|
**2026-05-17:** Decision recorded in State Hub:
|
|
`a0df816c-3749-4418-9c8b-28eb428be953`. Railiance S3 standardizes on
|
|
OpenBao as the runtime platform secrets service. SOPS/age remains the
|
|
Git-at-rest bootstrap mechanism.
|
|
|
|
### T02 - Kubernetes Deployment Design
|
|
|
|
```task
|
|
id: RAIL-PL-WP-0002-T02
|
|
status: done
|
|
priority: high
|
|
state_hub_task_id: "fb6ac85d-e77f-400d-8342-70a0ec6e82ef"
|
|
```
|
|
|
|
Design the OpenBao Helm deployment for Railiance: namespace, storage
|
|
backend, HA posture, ingress/internal service exposure, TLS, resource
|
|
limits, PodDisruptionBudget, NetworkPolicies, and upgrade/rollback
|
|
strategy.
|
|
|
|
**2026-05-17:** Implemented `helm/openbao-values.yaml`, Make targets, and
|
|
`docs/openbao.md`. Deployed chart `openbao/openbao` `0.28.2` (app
|
|
`v2.5.3`) to Railiance01 namespace `openbao` as internal-only,
|
|
single-replica Raft with data/audit PVCs. Public ingress remains disabled;
|
|
OpenBao is intentionally uninitialized and sealed until the bootstrap
|
|
ceremony.
|
|
|
|
### T03 - Bootstrap, Unseal, And Break-Glass Procedure
|
|
|
|
```task
|
|
id: RAIL-PL-WP-0002-T03
|
|
status: in_progress
|
|
priority: high
|
|
state_hub_task_id: "509ccfd4-1775-4be4-b8e4-8d5bcf17f91e"
|
|
```
|
|
|
|
Define initialization, unseal, root-token retirement, operator access,
|
|
emergency access, backup escrow, and recovery drill. Ensure the design
|
|
does not introduce an unmanaged "secret zero" worse than the current
|
|
SOPS/age bootstrap.
|
|
|
|
**2026-05-17:** Initial ceremony documented in `docs/openbao.md`. Still
|
|
needs human escrow assignment, root-token retirement details, and a
|
|
restore/recovery drill before live secrets move into OpenBao.
|
|
|
|
### T04 - Auth Methods And Workload Integration
|
|
|
|
```task
|
|
id: RAIL-PL-WP-0002-T04
|
|
status: todo
|
|
priority: high
|
|
state_hub_task_id: "ca2b3ac2-b522-4445-a418-c6ec312cd5f4"
|
|
```
|
|
|
|
Configure or document auth methods for Kubernetes workloads,
|
|
NetKingdom identity, admins, agents, and automations. Decide when
|
|
workloads use OpenBao directly, CSI-mounted secrets, External Secrets
|
|
Operator, or sidecars/controllers.
|
|
|
|
### T05 - Secret Engines And Dynamic Credentials
|
|
|
|
```task
|
|
id: RAIL-PL-WP-0002-T05
|
|
status: in_progress
|
|
priority: medium
|
|
state_hub_task_id: "0d717bdd-76bc-41b4-b633-ba07214b4095"
|
|
```
|
|
|
|
Enable and document the initial secret engines: KV v2 for platform
|
|
configuration, database dynamic credentials for CNPG-managed
|
|
PostgreSQL, Kubernetes token generation where appropriate, PKI/SSH
|
|
future paths, and an assessment of object-storage credential vending
|
|
integration with NK-WP-0007.
|
|
|
|
**2026-05-17:** Object-storage credential vending assessment started and
|
|
documented in `docs/openbao.md`. Existing `artifact-store` capabilities cover
|
|
artifact package preservation, an S3-compatible backend, env/file secret refs,
|
|
and `artifactstore storage verify --backend s3`. Railiance S3 should use
|
|
OpenBao for bootstrap custody, policy, audit, break-glass, and workload secret
|
|
delivery, while `artifact-store` owns S3 backend behavior and
|
|
`ARTIFACT-STORE-WP-0007` owns MinIO/fork compatibility plus temporary
|
|
credential refresh decisions. NetKingdom remains the default owner for OIDC
|
|
identity if object storage adopts `AssumeRoleWithWebIdentity`.
|
|
|
|
### T06 - Backup, Audit, Monitoring, And Verification
|
|
|
|
```task
|
|
id: RAIL-PL-WP-0002-T06
|
|
status: todo
|
|
priority: medium
|
|
state_hub_task_id: "cd61bc7d-8b9f-484f-97bd-7254c227b0ee"
|
|
```
|
|
|
|
Define backup/restore procedure, audit device configuration, metrics,
|
|
logs, health checks, restore drill, and smoke tests. Include a
|
|
developer/operator verification script for the deployed service.
|
|
|
|
### T07 - Cross-Repo Transition Tasks
|
|
|
|
```task
|
|
id: RAIL-PL-WP-0002-T07
|
|
status: in_progress
|
|
priority: medium
|
|
state_hub_task_id: "89149b60-562b-4a5b-978d-0f9136ffa114"
|
|
```
|
|
|
|
Create or link follow-up tasks for NetKingdom, ops-warden, ops-bridge,
|
|
artifact-store, and S5 applications where documentation or integration
|
|
must move from HashiCorp Vault-specific assumptions to OpenBao-first
|
|
or Vault-compatible abstraction language.
|
|
|
|
**2026-05-17:** Started cross-repo transition by updating
|
|
`net-kingdom/docs/platform-identity-security-architecture.md` and
|
|
`net-kingdom/SCOPE.md` so NetKingdom treats OpenBao as the runtime
|
|
platform secrets authority while SOPS/age remains bootstrap/Git-at-rest
|
|
protection. Still needs ops-warden, ops-bridge, artifact-store, S5 app,
|
|
and stale HashiCorp Vault wording follow-ups.
|
|
|
|
**2026-05-17:** Linked the artifact-store transition to
|
|
`ARTIFACT-STORE-WP-0007 - MinIO Compatibility, MaxIO Fork Assessment, And STS
|
|
Credential Vending` instead of creating duplicate S3 backend work in
|
|
`railiance-platform`. The OpenBao side of the handoff is now documented in
|
|
`docs/openbao.md`; remaining artifact-store work belongs in
|
|
`ARTIFACT-STORE-WP-0007-T004` and follow-up routing in
|
|
`ARTIFACT-STORE-WP-0007-T005`.
|
|
|
|
## Acceptance Criteria
|
|
|
|
- Railiance has an explicit decision on OpenBao versus HashiCorp Vault
|
|
for platform secrets management.
|
|
- OpenBao deployment topology is defined for the S3 platform-services
|
|
layer.
|
|
- Bootstrap, unseal, backup, restore, audit, and break-glass procedures
|
|
are documented before live secrets are migrated.
|
|
- Integration choices are clear for Kubernetes workloads, NetKingdom
|
|
identity, dynamic database credentials, and future object-storage STS
|
|
credential vending.
|
|
- SOPS/age remains the bootstrap Git-at-rest mechanism unless a later
|
|
ADR deliberately replaces it.
|