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>

docs/adr/ADR-0008-object-storage-sts-credential-vending.md

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