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.