Credentials

Credentials#

Resolved per volume, in this order. The first that applies wins.

1. Presigned mode, when presignEndpoint is set. The node holds no S3 credentials at all; the driver asks a signer service for a fresh URL per upload. Combining it with static credential keys in the same secret is rejected, since that would ship to the node exactly what the mode exists to avoid.
2. Per-volume secret via nodePublishSecretRef, with keys accessKeyId, secretAccessKey, optional sessionToken, or presignToken for presigned mode.
3. Driver-global S3A_ACCESS_KEY_ID, S3A_SECRET_ACCESS_KEY and S3A_SESSION_TOKEN.
4. AWS default provider chain, which is what makes IRSA, EKS Pod Identity and node instance profiles work with no driver configuration at all.

apiVersion: v1
kind: Secret
metadata:
  name: s3-creds
  namespace: team-a
stringData:
  accessKeyId: AKIAEXAMPLE
  secretAccessKey: "…"
---
# in the pod spec
csi:
  driver: s3archiver.csi.trion.de
  volumeAttributes:
    bucket: prod-dumps
  nodePublishSecretRef:
    name: s3-creds

The repository ships a reference signer for presigned mode, run as csi-s3-archiver presign-signer. It reads S3A_PRESIGN_PORT, S3A_PRESIGN_TOKEN (the bearer token the driver must present) and S3A_PRESIGN_EXPIRY_SECONDS, and it holds the S3 credentials the nodes do not. It is a starting point rather than a product: One static token, no TLS termination, no rate limiting and no audit log. The security page says what you would need to add.