Ozone S3 Security Token Service overview

The Ozone Security Token Service (STS) provides temporary, short-lived S3 credentials (AccessKeyId, SecretAccessKey, SessionToken) through the AWS-compatible AssumeRole API. It enables secure, fine-grained access to Ozone buckets without exposing long-term principal credentials or Kerberos keytabs.

Typically, Ozone S3 credentials are tied to a Kerberos identity. STS introduces a programmatic method to obtain temporary credentials, which include an access key, a secret key, and a session token. These credentials inherit permissions from a Ranger role and can optionally be further restricted by an inline IAM session policy.

Key functionalities include:

• Dedicated endpoint: Runs on a dedicated port (separate from the S3 Gateway port).
• API support: Implements the AWS AssumeRole specification.
• Authorization: Relies on Apache Ranger for role delegation and permission checking.

How Ozone STS works

The temporary credential generation and usage flow operates through the following steps:

1. Request: A user with long-term credentials calls AssumeRole API on the STS endpoint.
2. Validation: Ozone validates the request signature and queries Apache Ranger to confirm the caller is permitted to assume the target role.
3. Policy evaluation: If an optional inline IAM session policy is provided, Ozone intersects its permissions with the target Ranger role when the token is used.
4. Credential issuance: Ozone returns the following short-lived credentials:
   • AccessKeyId - Starting with the ASIA access key prefix
   • SecretAccessKey
   • SessionToken
5. Access: The client performs standard S3 operations using the temporary keys and including the SessionToken in the x-amz-security-token header.