fmorg-git commented on code in PR #510: URL: https://github.com/apache/ozone-site/pull/510#discussion_r3694204774
########## docs/04-user-guide/01-client-interfaces/03-s3/03-sts.md: ########## @@ -0,0 +1,591 @@ +--- +sidebar_label: 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. + +## 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](../../../administrator-guide/configuration/security/ranger)). +3. **Permanent S3 credentials** for the calling user (i.e. service principal): + + ```shell + kinit my-service-user + ozone s3 getsecret + # awsAccessKey=... + # awsSecret=... + ``` + +4. **Ozone volume(s), bucket(s) and key(s) created** as needed for the resources the STS tokens would need to access + +5. **Ranger user, roles and policies** (Ranger Admin configures): + - Create a Ranger **user** corresponding to the service principal in Ozone + - 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: + +```text +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. + +When configuring Ranger policies via `curl` (such as in the `Ranger Policy Setup` section below), 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). + +--- + +## 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. +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. + +--- + +## 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 all Ozone Managers and all S3 Gateways after changing this property to have it take effect. Datanodes, SCM, and Recon do not need to be restarted. + +**WARNING**: Do *NOT* enable STS without also enabling the corresponding flag on the Ranger side (see "Ranger feature flag" section below). If the Ozone feature flag is enabled but not the Ranger feature flag, it is possible for the created STS token to have more access than requested. For example, a token requested for the `s3:PutObject` action would have access to `s3:PutObject`, `s3:PutObjectTagging` and `s3:DeleteObjectTagging` actions, which is a security issue. Having both the Ozone and Ranger feature flags set to true prevents these scenarios from happening provided the Ranger policies are also set up correctly. + +### 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 one or more of the following URLs, depending on the `ozone.http.policy` value (`HTTP_ONLY`, `HTTPS_ONLY`, or `HTTP_AND_HTTPS`) and whether TLS is configured. By default, the value is `HTTP_ONLY`: + +```text +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> +``` + +<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 of the role permissions and actions and session policy permissions and actions. + +### 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 shows for each S3 action, 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> | +| `s3:CreateBucket` | Bucket | Permission: `READ`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `CreateBucket`</span> | Permission: `CREATE`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `CreateBucket`</span> | — | +| `s3:DeleteBucket` | Bucket | Permission: `READ`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `DeleteBucket`</span> | Permission: `DELETE`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `DeleteBucket`</span> | — | +| `s3:DeleteObject` | Object | Permission: `READ`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `DeleteObject`</span> | Permission: `READ`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `DeleteObject`</span> | Permission: `DELETE`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `DeleteObject`</span> | +| `s3:DeleteObjectTagging` | Object | Permission: `READ`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `DeleteObjectTagging`</span> | Permission: `READ`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `DeleteObjectTagging`</span> | Permission: `WRITE`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `DeleteObjectTagging`</span> | +| `s3:GetBucketAcl` | Bucket | Permission: `READ`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `GetBucketAcl`</span> | Permission: `READ`, `READ_ACL`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `GetBucketAcl`</span> | — | +| `s3:GetObject` | Object | Permission: `READ`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `GetObject`</span> | Permission: `READ`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `GetObject`</span> | Permission: `READ`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `GetObject`</span> | +| `s3:GetObjectTagging` | Object | Permission: `READ`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `GetObjectTagging`</span> | Permission: `READ`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `GetObjectTagging`</span> | Permission: `READ`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `GetObjectTagging`</span> | +| `s3:ListAllMyBuckets` | Volume | Permission: `READ`, `LIST`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `ListAllMyBuckets`</span> | — | — | +| `s3:ListBucket` | Bucket | Permission: `READ`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `ListBucket`</span> | Permission: `READ`, `LIST`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `ListBucket`</span> | Permission: `READ`†<br/><span style={{whiteSpace: 'nowrap'}}>Action: `ListBucket`</span> | +| `s3:ListBucketMultipartUploads` | Bucket | Permission: `READ`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `ListBucketMultipartUploads`</span> | Permission: `READ`, `LIST`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `ListBucketMultipartUploads`</span> | — | +| `s3:ListMultipartUploadParts` | Object | Permission: `READ`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `ListMultipartUploadParts`</span> | Permission: `READ`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `ListMultipartUploadParts`</span> | Permission: `READ`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `ListMultipartUploadParts`</span> | +| `s3:PutBucketAcl` | Bucket | Permission: `READ`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `PutBucketAcl`</span> | Permission: `READ`, `READ_ACL`, `WRITE_ACL`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `PutBucketAcl`</span> | — | +| `s3:PutObject` | Object | Permission: `READ`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `PutObject`</span> | Permission: `READ`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `PutObject`</span> | Permission: `CREATE`, `WRITE`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `PutObject`</span> | +| `s3:PutObjectTagging` | Object | Permission: `READ`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `PutObjectTagging`</span> | Permission: `READ`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `PutObjectTagging`</span> | Permission: `WRITE`<br/><span style={{whiteSpace: 'nowrap'}}>Action: `PutObjectTagging`</span> | + +</div> + +† For `s3:ListBucket`, key-level **READ** is granted on the listed prefix (or `*` if no `s3:prefix` condition is present). + +#### Simplifying bucket and key policies with `All` + +You can often simplify **bucket** and **key** policies by granting **`All`** instead of individual access types such as `write` or `delete`. The `action-matches` condition restricts which S3 action the permission applies to, so `All` with Action: `PutObject` does not broadly authorize unrelated operations at that resource level. + +At the **volume** level, prefer **specific** access types such as `read` and `list` rather than `All`. + +#### Example: IAM permission policy mapped to Ranger policies + +Suppose a role should support this IAM permission policy: + +```json +{ + "Version": "2012-10-17", + "Statement": [{ + "Effect": "Allow", + "Action": "s3:GetObject", + "Resource": "arn:aws:s3:::reports/*" + }] +} +``` + +The corresponding Ranger role needs matching policies at each level: + +| Level | Resource | Permission | Action-matches Policy Condition | +| --- | --- |--------------------|---------------------------------| +| Volume | `s3v` | `READ` | `GetObject` | +| Bucket | `reports` | `READ` (or `All`‡) | `GetObject` | +| Key | `*` (under `reports`) | `READ` (or `All`‡) | `GetObject` | + +‡ When using `All` at bucket or key level, the `action-matches: GetObject` condition is what prevents unrelated S3 actions from being authorized at that level. + +Example Ranger policy item for the key level (specific read permission): + +```json +{ + "accesses": [{ "type": "read", "isAllowed": true }], + "roles": ["my-data-reader-role"], + "conditions": [{ "type": "action-matches", "values": ["GetObject"] }] +} +``` + +Equivalent simplified key-level policy using `all`: + +```json +{ + "accesses": [{ "type": "all", "isAllowed": true }], + "roles": ["my-data-reader-role"], + "conditions": [{ "type": "action-matches", "values": ["GetObject"] }] +} +``` + +**WARNING**: Without `action-matches` on the volume, bucket and key policies, the same key-level `read` grant would also authorize `GetObjectTagging` and any other read-scoped S3 action at that path. Review Comment: updated - af79e8dd1d41a800ca6220fa5e37c6cba0e72d3f -- 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]
