generated from coulomb/repo-seed
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>
This commit is contained in:
87
docs/adr/ADR-0007-security-orchestration-boundary.md
Normal file
87
docs/adr/ADR-0007-security-orchestration-boundary.md
Normal file
@@ -0,0 +1,87 @@
|
||||
# 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.
|
||||
82
docs/adr/ADR-0008-object-storage-sts-credential-vending.md
Normal file
82
docs/adr/ADR-0008-object-storage-sts-credential-vending.md
Normal file
@@ -0,0 +1,82 @@
|
||||
# ADR-0008 - Object Storage STS Credential Vending Boundary
|
||||
|
||||
**Status:** Accepted
|
||||
**Date:** 2026-05-18
|
||||
**Deciders:** Bernd Worsch, Codex
|
||||
|
||||
## Context
|
||||
|
||||
NetKingdom needs a canonical pattern for issuing short-lived
|
||||
object-storage credentials to platform and tenant workloads. The first
|
||||
known consumer is `artifact-store`, but the pattern must work for future
|
||||
S3-compatible consumers without making each application repo own identity,
|
||||
authorization, root object-store credentials, or backend-specific STS
|
||||
differences.
|
||||
|
||||
The backend landscape is not uniform. AWS S3, Ceph RGW, and MinIO/AIStor
|
||||
can use web-identity STS-style flows. Cloudflare R2 exposes temporary
|
||||
credentials through a provider API or local signing with parent access
|
||||
material. OpenBao is now part of the Railiance platform stack as runtime
|
||||
secret authority, but it is not an identity provider or authorization
|
||||
policy engine.
|
||||
|
||||
## Decision
|
||||
|
||||
NetKingdom will define a provider-neutral credential-vending interface
|
||||
backed by provider-native temporary credential mechanisms where possible.
|
||||
|
||||
The trust path is:
|
||||
|
||||
1. IAM Profile token proves the actor or workload.
|
||||
2. flex-auth decides whether the actor may receive credentials for the
|
||||
requested protected system, tenant, bucket, prefix, action set, TTL,
|
||||
and assurance level.
|
||||
3. The credential-vending service exchanges the approved request with
|
||||
the backend-specific temporary credential mechanism.
|
||||
4. OpenBao stores parent credentials, broker configuration, lease
|
||||
metadata, and audit evidence where useful, but it does not replace
|
||||
flex-auth authorization.
|
||||
5. Consumers receive normalized temporary credentials containing access
|
||||
key id, secret access key, session token, and expiration.
|
||||
|
||||
## Consequences
|
||||
|
||||
- `artifact-store` needs temporary credential support, especially
|
||||
`AWS_SESSION_TOKEN` and refresh behavior, before it can fully consume
|
||||
the production vending pattern.
|
||||
- Backend-specific differences are isolated in the vending service, not
|
||||
leaked into application policy.
|
||||
- OpenBao remains runtime secret infrastructure and audit support; it
|
||||
does not become the object-storage policy source.
|
||||
- Provider-native STS is preferred when available because it gives the
|
||||
storage backend direct lease/expiration semantics.
|
||||
- Cloudflare R2 requires a broker path that protects parent access
|
||||
material, most likely through OpenBao custody.
|
||||
|
||||
## Alternatives Considered
|
||||
|
||||
### Give Applications Long-Lived Access Keys
|
||||
|
||||
This is simple but leaves applications holding durable credentials and
|
||||
pushes policy into ad hoc bucket configuration. It is acceptable only as
|
||||
a transitional bridge with scoped credentials and explicit rotation.
|
||||
|
||||
### Put Object-Storage Policy In Keycloak Or key-cape
|
||||
|
||||
Identity providers can assert who the actor is and coarse groups or
|
||||
roles, but they should not become the canonical source of bucket,
|
||||
prefix, action, TTL, and explanation semantics.
|
||||
|
||||
### Use OpenBao As The Credential Vending Policy Engine
|
||||
|
||||
OpenBao is valuable for secret custody, broker configuration, leases,
|
||||
and audit records. Making it the policy decision point would duplicate
|
||||
flex-auth, blur the platform/tenant boundary, and make authorization
|
||||
semantics backend-specific.
|
||||
|
||||
### Require One Backend Everywhere
|
||||
|
||||
A single backend would simplify implementation but does not match the
|
||||
platform direction. Railiance and NetKingdom need a stable security
|
||||
interface across AWS, self-hosted S3-compatible stores, and Cloudflare
|
||||
R2-like APIs.
|
||||
Reference in New Issue
Block a user