generated from coulomb/repo-seed
tegwick
7b211acd57
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>
88 lines
3.5 KiB
Markdown
88 lines
3.5 KiB
Markdown
# 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.
|