coulomb/railiance-platform
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
980947894ea3d123f319b5723f0471d936ad2e61
railiance-platform/workplans/RAIL-PL-WP-0002-openbao-platform-secrets-service.md

8.0 KiB
Raw Blame History

id, type, title, domain, repo, status, owner, topic_slug, planning_priority, planning_order, created, updated, depends_on, state_hub_workstream_id
id type title domain repo status owner topic_slug planning_priority planning_order created updated depends_on state_hub_workstream_id
RAIL-PL-WP-0002 workplan OpenBao Platform Secrets Service railiance railiance-platform active codex railiance high 2 2026-05-17 2026-05-17
RAIL-PL-WP-0001
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

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

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

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

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

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

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

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.
Reference in New Issue View Git Blame Copy Permalink