Files

tegwick 7b211acd57 Add OpenBao runtime secret authority; complete NK-WP-0006/0007/0008

Refine the recursive platform security architecture to make OpenBao the
canonical runtime secret authority, with SOPS/age, K8s Secrets, and the
emergency bundle reframed as bootstrap/delivery/break-glass mechanisms.

- credential-management standard v0.2: add OpenBao runtime authority
  section, rotation rules, and prohibited patterns (OpenBao-as-PDP,
  tenant platform-root)
- platform-identity-security-architecture: mark implemented; add
  flex-auth/Topaz implications, Coulomb onboarding path, and a
  production-readiness checklist
- NK-WP-0004/0005: document bootstrap-to-OpenBao handoff boundary
- NK-WP-0006/0007: status -> done with implementation reviews; add
  recursive platform/tenant split and OpenBao broker/audit role for
  object-storage STS vending
- NK-WP-0008: status -> done; repoint corpus to infospace-bench
- new ADR-0007 (orchestration boundary), ADR-0008 (STS vending
  boundary), and the object-storage STS credential-vending architecture

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

2026-05-20 22:51:20 +02:00

3.5 KiB

Raw Blame History

ADR-0007 - Security Orchestration Boundary

Status: Accepted Date: 2026-05-18 Deciders: Bernd Worsch, Codex

Context

The recursive platform security architecture needs careful sequencing: host trust, cluster trust, bootstrap secrets, runtime secret authority, runtime identity, runtime authorization, tenant onboarding, and readiness verification.

That sequencing crosses NetKingdom and Railiance ownership boundaries. NetKingdom owns the canonical security architecture, IAM Profile, credential/bootstrap standards, and authorization semantics. Railiance owns deployment layering for infrastructure, clusters, platform services, and applications. OpenBao adds an important runtime-secret authority to the platform control plane, but it does not change those ownership boundaries.

Creating a dedicated orchestration repo too early would risk encoding temporary bootstrap order and accidental stack assumptions as a permanent interface. Leaving every sequence implicit would also be risky: platform root actions, OpenBao initialization, policy import, and tenant onboarding must be auditable and repeatable.

Decision

Security orchestration will stay in Railiance playbooks for now.

NetKingdom will define the trust-state model, readiness checks, policy semantics, OpenBao boundaries, and tenant/control-plane rules. Railiance playbooks will own the concrete deployment sequencing across railiance-infra, railiance-cluster, railiance-platform, and railiance-apps.

A dedicated orchestration repo is deferred until the sequencing surface is stable enough to justify its own product boundary. If created later, it must coordinate safe sequencing and readiness reporting; it must not own security policy semantics or bypass Railiance stack ownership.

Consequences

NK-WP-0006 is implemented as architecture, standards, ADRs, and workplan constraints rather than a new repo.
OpenBao bootstrap, unseal/recovery, audit, backup, and workload-secret delivery belong in Railiance platform playbooks, governed by NetKingdom standards.
Cross-repo readiness should be reported as checks against explicit trust states, not as a hidden imperative script.
A future orchestration repo needs a new ADR before creation.

Future Repo Trigger

Revisit a dedicated orchestration repo only if at least two of these are true:

multiple Railiance deployments need the same security sequencing interface;
readiness reporting becomes a reusable artifact consumed by operators, agents, or CI;
rollback and recovery workflows need a cross-repo state machine that no single Railiance layer can own cleanly;
tenant onboarding becomes a repeatable workflow spanning identity, flex-auth, Topaz, OpenBao, object storage, and application repos.

Alternatives Considered

Create A Dedicated Orchestration Repo Now

This would give sequencing a visible home, but it would probably encode unstable details before OpenBao runtime operations, flex-auth/Topaz policy import, and tenant onboarding have enough implementation feedback.

Put Orchestration In NetKingdom

NetKingdom owns the security model, but it should not become the deployment repo for every stack layer. This would blur architecture ownership with platform deployment ownership.

Leave Sequencing Entirely Informal

This avoids premature structure but leaves bootstrap and runtime trust transitions too dependent on operator memory. The accepted approach keeps the sequence explicit while leaving concrete deployment in the Railiance stack.

3.5 KiB Raw Blame History