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

Raw Blame History

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:

IAM Profile token proves the actor or workload.
flex-auth decides whether the actor may receive credentials for the requested protected system, tenant, bucket, prefix, action set, TTL, and assurance level.
The credential-vending service exchanges the approved request with the backend-specific temporary credential mechanism.
OpenBao stores parent credentials, broker configuration, lease metadata, and audit evidence where useful, but it does not replace flex-auth authorization.
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.

3.4 KiB Raw Blame History