---
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.