fmorg-git commented on code in PR #9223: URL: https://github.com/apache/ozone/pull/9223#discussion_r2624563744
########## hadoop-hdds/docs/content/design/ozone-sts.md: ########## @@ -0,0 +1,214 @@ +--- +title: AWS STS Design for Ozone S3 +summary: STS Support in Ozone +date: 2025-10-30 +jira: HDDS-13323 +status: implementing +author: Madhan Neethiraj, Ren Koike, Fabian Morgan, Stephen O'Donnell, Istvan Fajth, Uma Maheswara Rao Gangumalla +--- +<!-- + Licensed under the Apache License, Version 2.0 (the "License"); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. See accompanying LICENSE file. +--> + +# AWS STS Design for Ozone S3 + +# 1. Introduction + +S3 credentials used to communicate with Ozone S3 APIs are based on a Kerberos identity. + +Historically, the Ozone community has had interest in a REST API capable of programmatically generating +temporary S3 credentials. + +Amazon AWS has the [Security Token Service (STS)](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) which +provides the ability to generate short-lived access to resources. + +The primary scope of this document is to detail the initial implementation of STS within the Ozone ecosystem. + +# 2. Why Use STS Tokens? + +Providing short-lived access to various resources in Ozone is useful in scenarios such as Data Lake +solutions that want to aggregate data across multiple cloud providers. + +# 3. How Ozone STS Works + +The initial implementation of Ozone STS supports only the [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) +API from the AWS specification. A new STS endpoint `/sts` on port `9880` (port `9881` for https) will be created to service STS requests in the S3 Gateway. +We use a separate port for STS to align with AWS so we don't have conflicts at a later time. This means we have: +- Admin port for Ozone specific S3 admin operations +- STS port for STS APIs, analogous to AWS' separate STS endpoint +- Existing dedicated port/endpoint for S3 object APIs. + +Furthermore, the initial implementation of Ozone STS focuses only on Apache Ranger for authorization in the first phase, +as it aligns more with IAM policies. Support for the Ozone Native Authorizer may be provided in a future phase. + +## 3.1 Capabilities + +The Ozone STS implementation has the following capabilities: + +- Create temporary credentials that last from a minimum of 15 minutes to a maximum of 12 hours. The +return value of the AssumeRole call will be temporary credentials consisting of 3 components: + - accessKeyId - a generated String identifier (cryptographically strong using SecureRandom) beginning with the sequence "ASIA" + - secretAccessKey - a generated String password (cryptographically strong using SecureRandom) + - sessionToken - a Base64-encoded opaque String identifier +- The temporary credentials will have the permissions associated with a role. Furthermore, an +[AWS IAM Session Policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) can +**optionally** be sent in the AssumeRole API call to limit the scope of the permissions further. If +an IAM policy is specified, the temporary credential will have the permissions comprising the intersection of the role permissions +and the IAM policy permissions. **Note:** If the IAM policy is specified and does not grant any permissions, then +the generated temporary credentials won't have any permissions and will essentially be useless. + +## 3.2 Limitations in AssumeRole API Support + +The AWS AssumeRole API has various required and optional fields. We will support the two required fields, i.e. `RoleArn` +and `RoleSessionName`. Additionally, we will support the following optional fields (all others will be rejected): +- `DurationSeconds` +- `Policy` + +## 3.3 Limitations in IAM Session Policy Support + +The AWS IAM policy specification is vast and wide-ranging. The initial Ozone STS implementation supports a limited +subset of its capabilities. The restrictions are outlined below: + +- The only supported prefix in ResourceArn is `arn:aws:s3:::` - all others will be rejected. **Note**: a ResourceArn +of `*` is supported as well. +- The only supported Condition operator is `StringEquals` - all others will be rejected. +- The only supported Condition key is `s3:prefix` - all others will be rejected. +- Only one Condition operator per Statement is supported - a Statement with more than one Condition will be rejected. +- The only supported Effect is `Allow` - all others will be rejected. +- If a (currently) unsupported S3 action is requested, such as `s3:GetAccelerateConfiguration`, it will be silently ignored. +Similarly, an invalid S3 action will be silently ignored. Review Comment: yes, I believe this behavior will need to be included in user docs. Also, if IIRC from previous discussions with an external team, the `silently ignored` behavior is what happens in AWS as well, at least in the `AssumeRole` call. When the token is used, it should fail though. Please see https://github.com/apache/ozone/pull/9223#discussion_r2511963255 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
