STS AssumeRole Session Policies: Resource-Based Policy Override Behavior

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.

Evaluation Uncertainty

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.

• Does an explicit Deny in an STS session policy override an Allow granted by a resource-based policy that targets the role ARN?
• How does the evaluation logic change when the resource policy uses Principal: "*" combined with aws:SourceAccount conditions?