fmorg-git commented on code in PR #510: URL: https://github.com/apache/ozone-site/pull/510#discussion_r3661570489
########## docs/05-administrator-guide/03-operations/16-sts.md: ########## @@ -0,0 +1,591 @@ +--- +sidebar_label: Ozone S3 STS +--- + +# Ozone S3 Security Token Service (STS) + +This guide explains how to enable, configure, and use Ozone STS to issue short-lived S3 credentials through the AWS-compatible (at least for the supported features) **AssumeRole** API. Ozone STS is designed for scenarios such as data-lake workloads that need temporary, scoped access to Ozone buckets and keys without distributing long-lived credentials. + +## Background + +Ozone S3 credentials are normally tied to a Kerberos identity. STS adds a programmatic path to obtain **temporary** credentials (access key, secret key, and session token) that inherit permissions from a Ranger **role**, optionally narrowed further by an inline **IAM session policy**. + +The initial implementation: + +- Exposes a dedicated STS endpoint on the S3 Gateway (separate from the S3 object API port). +- Support the **AssumeRole** API. +- Requires **Apache Ranger** for authorization. + +## How Ozone STS Works + +1. A user with permanent S3 credentials calls **AssumeRole** on the STS endpoint. +2. Ozone validates the request signature and asks Ranger whether the caller may assume the target role. +3. If an optional inline session policy (`Policy` parameter) is supplied, Ozone converts it to Ranger permissions and actions via the `IamSessionPolicyResolver` Java class. +4. On success, Ozone returns temporary credentials: + - **AccessKeyId** — begins with `ASIA` + - **SecretAccessKey** + - **SessionToken** — opaque, server-side stateless token +5. Subsequent S3 API calls use the temporary credentials and must include the session token in the `x-amz-security-token` header. If an optional inline session policy was supplied in the initial AssumeRole call, the permissions and actions for the inline policy will be intersected with the role's permissions for authorization. Otherwise, the role's permissions only will be used for authorization. + +Temporary credential lifetime is **15 minutes to 12 hours** (900–43,200 seconds). If `DurationSeconds` is omitted, the token's expiration defaults to 3600 seconds (1 hour) per the AWS specification. + +## Prerequisites + +Before using STS, you need: + +1. **Secure Ozone cluster** with Kerberos and Ranger enabled. +2. **Ranger Ozone plugin** installed on OM/S3G with `RangerOzoneAuthorizer` configured (see [Configuring Apache Ranger](../configuration/security/ranger)). +3. **Permanent S3 credentials** for the calling user: + +```shell +kinit my-service-user +ozone s3 getsecret +# awsAccessKey=... +# awsSecret=... +``` + +4. **Ranger roles and policies**: + - Create a Ranger **role** for each role that can be assumed. + - Grant the calling user **assume_role** permission on that role. + - Grant the role the resource permissions and actions it needs (volume/bucket/key) via resource policies. + +The role name in `RoleArn` must match the Ranger role name: + +``` +arn:aws:iam::123456789012:role/my-data-reader-role + ^^^^^^^^^^^^^^^^^^^^ + Ranger role name +``` + +The account ID (`123456789012`) is accepted for AWS compatibility but is not used for authorization. + +Set environment variable `RANGER_URL` to your Ranger Admin base URL (for example `http://localhost:6080`) and environment variable `RANGER_SERVICE` to your Ozone Ranger service name (for example `dev_ozone`). The curl examples below authenticate to Ranger Admin with `-u admin:rangerR0cks!` (replace with your Ranger Admin username and password). + +--- + +## Enabling STS + +### Ozone feature flag + +STS is disabled by default. Enable it in `ozone-site.xml`: + +```xml +<property> + <name>ozone.s3g.sts.http.enabled</name> + <value>true</value> + <description>Enable the Ozone S3 Gateway STS endpoint.</description> +</property> +``` +Restart Ozone after changing this property to have it take effect. + +### Additional Configurable Properties + +| Property | Default | Description | +| --- |----------------|-----------------------------------------------------------------| +| `ozone.s3g.sts.http.enabled` | `false` | Feature flag for the STS endpoint | +| `ozone.s3g.sts.http-address` | `0.0.0.0:9880` | HTTP STS bind address | +| `ozone.s3g.sts.https-address` | `0.0.0.0:9881` | HTTPS STS bind address | +| `ozone.s3g.sts.http-bind-host` | `0.0.0.0` | HTTP bind host (overrides hostname portion of `http-address`) | +| `ozone.s3g.sts.https-bind-host` | `0.0.0.0` | HTTPS bind host | +| `ozone.om.sts.token.cleanup.service.interval` | `3h` | Interval for cleaning revoked token entries older than 12 hours | +| `ozone.om.sts.token.cleanup.service.timeout` | `15m` | Timeout for a cleanup run | + +After enabling, the STS endpoint is available at: + +``` +http://<s3g-host>:9880/sts +https://<s3g-host>:9881/sts +``` + +The S3 object API remains on the existing S3G port (typically `9878`). + +### Ranger feature flag (action-matches Policy Condition) + +To enforce **S3 action-level** restrictions in Ranger policies (required for fine-grained STS behavior such as separating `GetObject` from `GetObjectTagging` at the same key path), enable the Ozone service-def option in Ranger Admin: + +```xml +<!-- ranger-admin-site.xml --> +<property> + <name>ranger.servicedef.ozone.enableActionMatcherInPoliciesCondition</name> + <value>true</value> +</property> +``` + +Property in `ranger-admin-site.xml`: + +`ranger.servicedef.ozone.enableActionMatcherInPoliciesCondition` + +<div style={{overflowX: 'auto'}}> + +| Default | When `false` | When `true` | +| --- |-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| --- | +| `false` | Ranger evaluates only Ozone access types (`read`, `write`, `create`, etc.). S3 actions from session policies are not enforced at action granularity, neither is it possible to specify granular actions on the role itself. | Enables the **Action** (`action-matches`) policy condition. The S3 Gateway passes the IAM action (for example `PutObject`) to Ranger on each request. | + +</div> + +When this flag is enabled: + +- Ranger policies can use the **Action** condition with values such as `PutObject`, `GetObject`, `ListBucket`, or wildcards like `Get*`. +- Inline session policies from AssumeRole carry S3 action constraints that Ranger enforces alongside ACL permissions. + +Restart Ranger Admin after changing this property so the updated Ozone service definition (including the `action-matches` condition) is loaded. + +--- + +## IAM Session Policy to Ranger Permission/Action Mapping + +When a caller passes a `Policy` parameter to AssumeRole, Ozone parses the AWS IAM session policy JSON and maps each supported S3 action to Ranger permissions and actions at **volume**, **bucket**, and **key** levels. Ranger then authorizes based on the intersection: + +``` +authorized permissions = role permissions ∩ session policy permissions +``` + +### Supported session policy subset + +| IAM element | Supported | Notes | +| --- | --- |------------------------------------------------------------------------------------------------------------------------------------------| +| `Effect` | `Allow` only | `Deny` and other effects are rejected | +| `Action` | Supported S3 actions and wildcards (`s3:*`, `s3:Get*`, `s3:Put*`, `s3:List*`, `s3:Create*`, `s3:Delete*`) | Unknown actions are **silently ignored** similar to AWS behavior (AssumeRole still succeeds; credentials simply won't grant that action) | +| `Resource` | `arn:aws:s3:::` prefix or `*` | Other ARN prefixes are rejected | +| `Condition` | `StringEquals` or `StringLike` with key `s3:prefix` | Only one condition operator per statement; only applies to `s3:ListBucket` | +| Policy size | ≤ 2048 characters | Matches AWS AssumeRole limit | + +### S3 action → Ranger permissions and actions + +The table below is derived from the `IamSessionPolicyResolver` Java class. For each S3 action, it shows which Ranger permissions and actions are required at each resource level when that action appears in a session policy. + +Each applicable resource level must also include a matching `action-matches` condition for that S3 action (for example `PutObject` at volume, bucket, and key for object-scoped actions). If `action-matches` is omitted at a level, the ACL permission applies to **every** S3 action that requires that ACL at that level. For example, key-level `READ` without `action-matches` authorizes both `GetObject` and `GetObjectTagging`. It is **imperative** (for security reasons) to specify the action at every applicable level. + +<div style={{overflowX: 'auto'}}> + +| S3 Action | Scope | Volume | Bucket | Key | +| --- | --- | --- | --- | --- | +| `s3:AbortMultipartUpload` | Object | Permission: `READ`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `AbortMultipartUpload`</span> | Permission: `READ`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `AbortMultipartUpload`</span> | Permission: `WRITE`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `AbortMultipartUpload`</span> | Review Comment: The tags are just for table formatting. In my opinion, it didn't look user-friendly without them. The surrounding `<div style={{overflowX: 'auto'}}>` keeps wide tables readable on narrow screens (it enables horizontal scrolling instead of overflowing). Inside table cells, Markdown tables don’t have a great “multi-line cell” syntax, so `<br/>` is used to put `Permission: ... ` and `Action: ... `on separate lines. The `<span style={{whiteSpace: 'nowrap'}}>` prevents “`Action: …” `from wrapping awkwardly (it’s most noticeable on smaller viewports). -- 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]
