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