Service Accounts and STS

RustFS provides two mechanisms for issuing credentials that are derived from an existing identity: service accounts (long-lived access keys owned by a parent user) and STS temporary credentials (short-lived keys with a session token).

Service Accounts

A service account is an access key/secret key pair that belongs to a parent IAM user (or to the root account). It authenticates like a normal key but is authorized as its parent:

• Inherited policy (default). If the service account is created without a policy, it inherits whatever the parent user's combined policies allow at request time.
• Session-bound policy. If a policy document is supplied at creation, it is embedded into the service account. Requests must then be allowed by both the parent's policies and the embedded policy.
• Expiration. An optional expiration timestamp (RFC 3339) can be set; the credential stops working after that time.

Service accounts cannot call AssumeRole, and a service account access key cannot be turned into a regular IAM user.

In the Console, service accounts are managed on the Access Keys page — see Access Key Management. The admin API exposes:

Creation body (all fields optional unless noted):

{
  "policy": { "Version": "2012-10-17", "Statement": [] },
  "targetUser": "alice",
  "accessKey": "myserviceaccount",
  "secretKey": "mysecret",
  "name": "ci-pipeline",
  "description": "Key used by CI",
  "expiration": "2027-01-01T00:00:00Z"
}

STS Temporary Credentials

RustFS implements an AWS-compatible STS endpoint at the server root (POST / with form-encoded parameters). Two actions are supported:

• AssumeRole — for existing IAM identities, signed with SigV4.
• AssumeRoleWithWebIdentity — for OIDC identities, authenticated by the JWT itself (see External Identity (OIDC)).

AssumeRole

The request must be signed (AWS Signature V4) by a long-term IAM credential — temporary credentials and service accounts cannot call AssumeRole. The calling identity also needs the sts:AssumeRole action allowed by its policies (all built-in policies include it).

Form parameters:

Example:

curl -s -X POST "https://rustfs.example.com/" \
  --user "$ACCESS_KEY:$SECRET_KEY" \
  --aws-sigv4 "aws:amz:us-east-1:s3" \
  -d "Action=AssumeRole" \
  -d "Version=2011-06-15" \
  -d "DurationSeconds=3600"

The response is an XML AssumeRoleResponse containing AccessKeyId, SecretAccessKey, SessionToken, and Expiration. Use all three values on subsequent S3 requests (the session token goes in X-Amz-Security-Token).

The temporary credential inherits the caller's policies; the parent of the credential is the calling access key. If a Policy parameter was supplied, it is stored in the session and applied as an additional restriction.

AssumeRoleWithWebIdentity

Used by the OIDC flow; no SigV4 signature is needed because the identity provider's JWT is the authentication:

RustFS verifies the token against the configured provider (signature, issuer, audience, expiry), maps its groups/roles claims to RustFS policy names, and rejects the request if no policies or groups can be mapped. The response is an XML AssumeRoleWithWebIdentityResponse with the same credential fields plus SubjectFromWebIdentityToken.