Skip to main content

AWS Credentials

SereneDB can read and write AWS resources — files in S3, and Iceberg tables in the S3 Tables and Glue catalogs. Unlike Google Cloud, AWS does not use expiring bearer tokens for these services: every request is individually signed (Signature Version 4) with a static key pair, so there is nothing to mint or renew — the credential you configure is used as-is, for both the catalog plane and the data files. You configure it once, through the Secrets manager.

Which credential should I use?​

Your situationUse
ProductionAccess keys of a dedicated least-privilege IAM identity
Temporary credentials from STS / an assumed roleSession tokens
S3-compatible stores (MinIO, Cloudflare R2, Tigris, ...)Custom endpoints, or the dedicated r2 secret type

Access keys​

The standard AWS credential: an access key id (AKIA...) and a secret access key, belonging to an IAM identity. For a database, create a dedicated IAM user so the keys survive employee departures and can be scoped to exactly what SereneDB needs:

# 1. Create the user
aws iam create-user --user-name serenedb-engine

# 2. Grant it access — attach a least-privilege policy (see below)
aws iam attach-user-policy --user-name serenedb-engine \
--policy-arn arn:aws:iam::123456789012:policy/serenedb-engine-access

# 3. Create the key pair (the secret is shown exactly once — store it safely)
aws iam create-access-key --user-name serenedb-engine

For the policy, start from AWS's managed policies and narrow down: AmazonS3TablesReadOnlyAccess / AmazonS3TablesFullAccess for S3 Tables, Glue's IAM actions for the Glue catalog, and plain s3:GetObject/s3:PutObject/s3:ListBucket on the specific buckets for data files.

Configure the keys as an S3 secret — REGION is required (Iceberg catalog attaches derive their endpoint region from it):

Query
CREATE PERSISTENT SECRET aws (    TYPE S3,    KEY_ID '⟨AKIA...⟩',    SECRET '⟨aws secret access key⟩',    REGION '⟨us-east-1⟩');

Production-friendly, with the usual static-key caveats: the key never expires on its own, so rotate it on your schedule and delete keys of decommissioned deployments.

Session tokens​

If your organization issues only temporary credentials — from STS, an assumed role, or SSO tooling — they come as a triple that includes a session token:

Query
CREATE SECRET aws_temp (    TYPE S3,    KEY_ID '⟨ASIA...⟩',    SECRET '⟨temporary secret access key⟩',    SESSION_TOKEN '⟨session token⟩',    REGION '⟨us-east-1⟩');

S3-compatible stores​

The same S3 secret type speaks to any S3-compatible service — point it at the service's endpoint:

Query
CREATE PERSISTENT SECRET minio (    TYPE S3,    KEY_ID '⟨key⟩',    SECRET '⟨secret⟩',    ENDPOINT '⟨minio.example.com:9000⟩',    URL_STYLE 'path',    USE_SSL false);

Cookbooks with service-specific settings: Cloudflare R2, Tigris, Fastly.

Scoping secrets to paths​

When different buckets need different credentials, give each secret a SCOPE — it is matched against data-file paths, longest prefix first:

Query
CREATE PERSISTENT SECRET aws_finance (    TYPE S3,    KEY_ID '⟨AKIA...⟩',    SECRET '⟨secret⟩',    REGION '⟨eu-central-1⟩',    SCOPE 's3://finance-lake');
CREATE PERSISTENT SECRET aws_logs (    TYPE S3,    KEY_ID '⟨AKIA...⟩',    SECRET '⟨secret⟩',    REGION '⟨us-east-1⟩',    SCOPE 's3://log-archive');

Putting a credential to work​

To attach an S3 Tables or Glue Iceberg catalog with the secret, see Iceberg catalog authentication. To read and write plain files, see S3 Import, S3 Export, and S3 Iceberg Import.