IAM Session Policy to Ranger permission or 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 the volume, bucket, and key levels. Ranger then authorizes access based on the intersection of the permissions and actions defined in the role and those defined in the session policy.

Supported session policy subset

Table 1. 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, but credentials simply will not 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 is allowed per statement; it only applies to `s3:ListBucket`.
`Policy Size`	≤ 2048 characters	Matches the AWS AssumeRole limit.

S3 action to Ranger permissions and actions mapping

The following table outlines the required Ranger permissions and actions at each resource level for each S3 action when it appears in a session policy.

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 the specific S3 action to which the permission applies, meaning All with Action: PutObject will not broadly authorize unrelated operations at that resource level.

At the volume level, use specific access types such as read and list rather than All. Volume-level permissions apply even when a request has no mapped S3 action (similar to bucket-level and key-level permissions). Therefore, granting All on a volume could unintentionally allow destructive operations, such as volume deletion, when the role is used outside the S3 context.

Example: IAM permission policy mapped to Ranger policies

Suppose a role should support this IAM permission policy:

{
  "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.

Examples:

Ranger policy item for the key level (specific read permission):

{
  "accesses": [{ "type": "read", "isAllowed": true }],
  "roles": ["my-data-reader-role"],
  "conditions": [{ "type": "action-matches", "values": ["GetObject"] }]
}

Equivalent simplified key-level policy using all:

{
  "accesses": [{ "type": "all", "isAllowed": true }],
  "roles": ["my-data-reader-role"],
  "conditions": [{ "type": "action-matches", "values": ["GetObject"] }]
}

s3:prefix condition (ListBucket only)

If an IAM session policy or role permission policy statement includes a Condition, only s3:ListBucket from that statement takes effect (similar to AWS behavior).


Operator	Behavior
`StringEquals`	Exact prefix match; wildcard values in `s3:prefix` are ignored.
`StringLike`	Prefix pattern match; supports `*` wildcards

The caller supplies a matching prefix (and optionally a delimiter) for ListObjects or ListObjectsV2, or access is denied.