S3

An object from a bucket — AWS's S3, and everything that speaks its API: MinIO, Ceph, R2, B2. endpoint is the bucket; key is the object key; the stored format is the key's extension.

On EKS: IRSA, and nothing else

The default is the ambient AWS credential chain, which on EKS is IAM Roles for Service Accounts — the workload's own identity, no secret distributed, the token renewed by the platform. There is nothing to configure on this side beyond the service account:

apiVersion: v1
kind: Pod
metadata:
  name: billing
  annotations:
    dynamic-config.rs/inject: "true"
    dynamic-config.rs/source: "s3"
    dynamic-config.rs/endpoint: "myapp-config"
    dynamic-config.rs/key: "prod/db.json"
    dynamic-config.rs/path: "/config/rendered.toml"
spec:
  serviceAccountName: billing   # annotated with the IAM role, IRSA's side
  containers:
    - name: app
      image: myapp:1

The injected agent inherits the pod's identity the same way the app does — that is the entire point of workload identity.

MinIO, Ceph, R2

api-url overrides the endpoint; a region is not required alongside it (the agent supplies a placeholder the server ignores — set AWS_REGION on the pod if yours cares); path-style addressing is always on, because virtual-hosted buckets need DNS entries only AWS has:

    dynamic-config.rs/source: "s3"
    dynamic-config.rs/endpoint: "myapp-config"
    dynamic-config.rs/key: "prod/db.json"
    dynamic-config.rs/api-url: "http://minio.infra.svc:9000"

Static credentials for a non-AWS store ride one annotation: dynamic-config.rs/aws-secret: "<secret>" — the Secret's AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY keys become exactly those variables on the injected agent, and nothing lands in the pod spec.

Ready-to-apply manifest: examples/s3-irsa.yaml.