Question
STS AssumeRole Session Policies: Resource-Based Policy Override Behavior
Zo Echo
0 reputation · 23 Jan 2022, 02:06 UTC
146.9K views
Loading…
0 reputation · 23 Jan 2022, 02:06 UTC
When testing integrations without modifying production IAM roles, AWS STS AssumeRole allows passing an optional session policy to further restrict the permissions of the resulting temporary credentials. This is intended to enforce least-privilege access during integration tests by filtering the base role's permissions.
There is uncertainty regarding how these session policies interact with resource-based policies (such as S3 bucket policies or KMS key policies) in cross-account scenarios. Specifically, if a resource-based policy grants access to a role ARN via a condition key like aws:PrincipalArn, it is unclear if an explicit Deny within the session policy consistently overrides that resource-level Allow.
Furthermore, the IAM Policy Simulator may not fully replicate this specific layering of session policies and cross-account resource policies, making it difficult to verify restrictions before deployment.
Deny in an STS session policy override an Allow granted by a resource-based policy that targets the role ARN?Principal: "*" combined with aws:SourceAccount conditions?35275 reputation · 23 Jan 2022, 05:34 UTC
1. Yes, an explicit Deny in an STS session policy always overrides any Allow granted by a resource-based policy, regardless of whether the resource policy targets the role ARN specifically.
2. When a resource policy uses Principal: "*" combined with aws:SourceAccount, the evaluation logic remains the same: the session policy acts as a filter. An explicit Deny in that session policy will block the request even if the resource policy permits all principals from the specified account.
AWS IAM evaluation follows a strict hierarchy where an explicit deny always takes precedence over any allow. In the case of STS session policies, the following rules apply:
awsDeny is the highest priority in the IAM evaluation logic, it overrides permissions granted by identity-based policies, session policies, and resource-based policies.Allow in both the identity-based policy (or session policy) and the resource-based policy. However, a Deny in either location will result in an overall denial.To verify this behavior in a test environment, follow these steps:
s3:GetObject for Principal: "*" with a condition "aws:SourceAccount": "AccountA_ID".s3:GetObject on the Account B bucket.sts:AssumeRole and pass a session policy containing an explicit Deny for s3:GetObject on that specific bucket resource.GetObject call. The request will return AccessDenied, confirming the session policy override.To ensure this behavior is what you are observing, please confirm: Does the base IAM role's identity-based policy already contain an Allow for the action you are testing? (Session policies cannot grant permissions that the base role lacks).
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 23 Jan 2022, 08:16 UTC
To clarify the evaluation logic: an explicit Deny in an STS session policy always takes precedence, regardless of whether the Allow originates from an identity-based policy or a resource-based policy. In AWS IAM evaluation, a single explicit Deny overrides any Allow across all applicable policy types.
In cross-account scenarios, the behavior differs based on the resource policy's principal:
Allow in both the resource policy and the identity-based policy. A session policy Deny breaks this chain.aws:SourceAccount), the resource policy provides the Allow, but the session policy still acts as a final filter. If the session policy contains an explicit Deny, the request is rejected.Practical verification can be performed by attempting a s3:GetObject call using temporary credentials where the session policy explicitly denies the action, even if the S3 bucket policy explicitly allows the role ARN.