Skip to main content
Version: Next

HDDS-13323: Ozone S3 Security Token Service (STS)

Epic: HDDS-13323 Feature branch: https://github.com/apache/ozone/tree/HDDS-13323-sts

1. Builds/intermittent test failures​

There are no intermittent failures specific to the HDDS-13323-sts branch as of now. During development, it was ensured that all CI checks were clean prior to every commit merge.

The plan is to run repeated CI checks on the merge commit to master.

2. Documentation​

User documentation for Ozone S3 Security Token Service (STS) has been added.

3. Design, attached the docs​

Design document can be found here: AWS STS Design for Ozone S3.

4. S3 compatibility​

See sections 3.2 and 3.3 in the design document for limitations in the AssumeRole API compatibility.

Also please note that the Ranger feature flag (along with the Ozone feature flag) must be enabled in order to get AWS compatibility in terms of the requested actions and resulting actions the STS tokens have.

5. Docker-compose / Acceptance tests​

New robot tests ozone-secure-sts.robot and ozone-secure-sts-multitenant.robot are being added. Furthermore, a shell script to test Polaris with Ozone STS (polaris-smoketest.sh) is being added.

6. Support of containers / Kubernetes​

No addition. No change in existing support.

7. Coverage / Code quality​

New Code Coverage for STS (HDDS-13323-sts) is 81.07% and Overall Code Coverage is 78.7%. Overall Code Coverage for master is 78.8%.

8. Build time​

Build time for the latest commit from HDDS-13323-sts branch is 12m 46s. Build time for the latest commit from the master branch is 12m 15s.

9. Possible incompatible changes/used feature flag​

STS is disabled by default and gated by configuration flags. Both flags below must be enabled for correct, fine-grained authorization behavior.

Ozone feature flag​

Enable in ozone-site.xml:

<property>
  <name>ozone.s3g.sts.http.enabled</name>
  <value>true</value>
  <description>Enable the Ozone S3 Gateway STS endpoint.</description>
</property>

Ranger feature flag (action-matches Policy Condition)​

Enable in ranger-admin-site.xml:

<property>
  <name>ranger.servicedef.ozone.enableActionMatcherInPoliciesCondition</name>
  <value>true</value>
</property>

A new OM RocksDB table, s3RevokedStsTokenTable (originalAccessKeyId → revocationTimeMillis), stores revocation cut off time entries per originalAccessKeyId. No OM versioning-framework feature flag is used.

10. Third-party dependencies/License changes​

There are no third party dependencies introduced by this feature.

11. Performance​

The AssumeRole invocations are write requests and therefore the throughput is shared with other OM write calls.

12. Security considerations​

STS introduces a new network-accessible endpoint (ports 9880/9881) for AssumeRole. Key security properties:

  • Temporary credentials only: AssumeRole requires permanent S3 credentials (from ozone s3 getsecret) of a Kerberos identity to create the temporary credentials. Temporary credentials expire between 15 minutes and 12 hours.
  • Ranger-only authorization: STS requires Apache Ranger with role-based policies and optional inline IAM session policies.
  • Fail-closed revocation checks: If the revocation database is unavailable, token validation fails rather than allowing access.

Token revocation​

Ozone adds explicit revocation support:

Revoke all tokens created by Kerberos identity before a cutoff point — only the Kerberos identity corresponding to the originalAccessKeyId or an S3/tenant admin may revoke. This adds the originalAccessKeyId to the OM RocksDB s3RevokedStsTokenTable. Subsequent S3 requests using session tokens created by that originalAccessKeyId before the revocation cutoff point are denied immediately, even before the token's natural expiration.

Revoke all tokens for a user — revoking a user's permanent S3 secret also invalidates all outstanding STS tokens created by that user. This is useful when a long-lived credential is compromised and all derived temporary credentials must be invalidated at once.