Add OpenBao platform secrets workplan
This commit is contained in:
183
workplans/RAIL-PL-WP-0002-openbao-platform-secrets-service.md
Normal file
183
workplans/RAIL-PL-WP-0002-openbao-platform-secrets-service.md
Normal file
@@ -0,0 +1,183 @@
|
||||
---
|
||||
id: RAIL-PL-WP-0002
|
||||
type: workplan
|
||||
title: "OpenBao Platform Secrets Service"
|
||||
domain: railiance
|
||||
repo: railiance-platform
|
||||
status: proposed
|
||||
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: todo
|
||||
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.
|
||||
|
||||
### T02 - Kubernetes Deployment Design
|
||||
|
||||
```task
|
||||
id: RAIL-PL-WP-0002-T02
|
||||
status: todo
|
||||
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.
|
||||
|
||||
### T03 - Bootstrap, Unseal, And Break-Glass Procedure
|
||||
|
||||
```task
|
||||
id: RAIL-PL-WP-0002-T03
|
||||
status: todo
|
||||
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.
|
||||
|
||||
### 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: todo
|
||||
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.
|
||||
|
||||
### 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: todo
|
||||
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.
|
||||
|
||||
## 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.
|
||||
Reference in New Issue
Block a user