|
| 1 | +# HDDS-13323: Ozone S3 Security Token Service (STS) |
| 2 | + |
| 3 | +Epic: [HDDS-13323](https://issues.apache.org/jira/browse/HDDS-13323) |
| 4 | +Feature branch: https://github.com/apache/ozone/tree/HDDS-13323-sts |
| 5 | + |
| 6 | +## 1. Builds/intermittent test failures |
| 7 | + |
| 8 | +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. |
| 9 | + |
| 10 | +The plan is to run repeated CI checks on the merge commit to master. |
| 11 | + |
| 12 | +## 2. Documentation |
| 13 | + |
| 14 | +[User documentation](https://ozone.apache.org/docs/next/administrator-guide/operations/s3/sts) for Ozone S3 Security Token Service (STS) has been added. |
| 15 | + |
| 16 | +## 3. Design, attached the docs |
| 17 | + |
| 18 | +Design document can be found here: [AWS STS Design for Ozone S3](https://github.com/apache/ozone/blob/HDDS-13323-sts/hadoop-hdds/docs/content/design/ozone-sts.md). |
| 19 | + |
| 20 | +## 4. S3 compatibility |
| 21 | + |
| 22 | +See sections [3.2](https://github.com/apache/ozone/blob/HDDS-13323-sts/hadoop-hdds/docs/content/design/ozone-sts.md#32-limitations-in-assumerole-api-support) and [3.3](https://github.com/apache/ozone/blob/HDDS-13323-sts/hadoop-hdds/docs/content/design/ozone-sts.md#33-limitations-in-iam-session-policy-support) in the design document for limitations in the AssumeRole API compatibility. |
| 23 | + |
| 24 | +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. |
| 25 | + |
| 26 | +## 5. Docker-compose / Acceptance tests |
| 27 | + |
| 28 | +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. |
| 29 | + |
| 30 | +## 6. Support of containers / Kubernetes |
| 31 | + |
| 32 | +No addition. No change in existing support. |
| 33 | + |
| 34 | +## 7. Coverage / Code quality |
| 35 | + |
| 36 | +[New Code Coverage](https://sonarcloud.io/summary/new_code?id=hadoop-ozone&branch=HDDS-13323-sts) for STS (HDDS-13323-sts) is **89.1%** and [Overall Code Coverage](https://sonarcloud.io/summary/overall?id=hadoop-ozone&branch=HDDS-13323-sts) is **75.4%**. |
| 37 | +[Overall Code Coverage](https://sonarcloud.io/summary/overall?id=hadoop-ozone&branch=master) for master is **78.5%**. |
| 38 | + |
| 39 | +## 8. Build time |
| 40 | + |
| 41 | +[Build time for the latest commit](https://github.com/apache/ozone/actions/runs/30604883966/job/91075071143) from HDDS-13323-sts branch is **11m 32s**. |
| 42 | +[Build time for the latest commit](https://github.com/apache/ozone/actions/runs/30662032542/job/91260363408) from the master branch is **11m 48s**. |
| 43 | + |
| 44 | +## 9. Possible incompatible changes/used feature flag |
| 45 | + |
| 46 | +STS is disabled by default and gated by configuration flags. **Both** flags below must be enabled for correct, fine-grained authorization behavior. |
| 47 | + |
| 48 | +### Ozone feature flag |
| 49 | + |
| 50 | +Enable in `ozone-site.xml`: |
| 51 | + |
| 52 | +```xml |
| 53 | +<property> |
| 54 | + <name>ozone.s3g.sts.http.enabled</name> |
| 55 | + <value>true</value> |
| 56 | + <description>Enable the Ozone S3 Gateway STS endpoint.</description> |
| 57 | +</property> |
| 58 | +``` |
| 59 | + |
| 60 | +### Ranger feature flag (action-matches Policy Condition) |
| 61 | + |
| 62 | +Enable in `ranger-admin-site.xml`: |
| 63 | + |
| 64 | +```xml |
| 65 | +<property> |
| 66 | + <name>ranger.servicedef.ozone.enableActionMatcherInPoliciesCondition</name> |
| 67 | + <value>true</value> |
| 68 | +</property> |
| 69 | +``` |
| 70 | + |
| 71 | +A new RocksDB table stores revoked STS token entries. No OM versioning-framework feature flag is used. |
| 72 | + |
| 73 | +## 10. Third-party dependencies/License changes |
| 74 | + |
| 75 | +There are no third party dependencies introduced by this feature. |
| 76 | + |
| 77 | +## 11. Performance |
| 78 | + |
| 79 | +The AssumeRole invocations are write requests and therefore the throughput is shared with other OM write calls. |
| 80 | + |
| 81 | +## 12. Security considerations |
| 82 | + |
| 83 | +STS introduces a new network-accessible endpoint (ports 9880/9881) for AssumeRole. Key security properties: |
| 84 | + |
| 85 | +- **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. |
| 86 | +- **Ranger-only authorization**: STS requires Apache Ranger with role-based policies and optional inline IAM session policies. |
| 87 | +- **Fail-closed revocation checks**: If the revocation database is unavailable, token validation fails rather than allowing access. |
| 88 | + |
| 89 | +### Token revocation |
| 90 | + |
| 91 | +Ozone adds explicit revocation support: |
| 92 | + |
| 93 | +**Revoke a single session token** — only the token creator or an S3/tenant admin may revoke. This adds the token to an OM RocksDB revoked-token table. Subsequent S3 requests using that session token are denied immediately, even before the token's natural expiration. |
| 94 | + |
| 95 | +**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. |
0 commit comments