benkehoe / permissions-boundary-test

Demonstration that AWS IAM policy evaluation docs are incorrect

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Read the accompanying article.

The flowchart from the AWS IAM policy evaluation documentation page, as of 2021-09-12, and dating back to at least 2018-12-27, is the following:

Flowchart

The flowchart indicates that an Allow in a resource policy causes a final decision of Allow, before permissions boundaries have a chance to cause an implicit Deny. This would mean a resource policy could unilaterally grant access to a principal, circumventing its permissions boundary. However, this is only partially correct.

Resource policies cannot unilaterally grant access to an IAM role but can unilaterally grant access to particular role sessions, that is, the thing that is created by calling AssumeRole. This is mentioned in the docs here, illustrated with the following diagram, though this information is excluded from subsequent diagrams about SCPs and session policies.

VennDiagram

This is true for assumed role sessions created with AssumeRole (and presumably AssumeRoleWithSAML and AssumeRoleWithWebIdentity), where the principal in the resource policy is the assumed role session ARN, which is retrievable through the GetCallerIdentity API, which does not require permissions.

This also applies "federated users" but this does not mean an assumed role session using AssumeRoleWithSAML with a federated identity provider; it refers to sessions created with GetFederationToken using IAM User credentials. Note that the usage of "federated user" is inconsistent in the IAM documentation, used to refer to both kinds of federation.

Verification

For an IAM role with a permissions boundary, role policy, and resource policy, none with any Denys, the possible combinations of Allows in the policy have the following results:

Role as resource policy principal

Permissions Boundary Role Policy Resource Policy Result
- - Allow Deny
- Allow Allow Deny
Allow Allow - Allow
Allow - Allow Allow
Allow Allow Allow Allow
Allow - - Deny
- Allow - Deny

Assumed role session as resource policy principal

Permissions Boundary Role Policy Resource Policy Result
- - Allow Allow
- Allow Allow Allow
Allow Allow - Allow
Allow - Allow Allow
Allow Allow Allow Allow
Allow - - Deny
- Allow - Deny

Account as resource policy principal, with role in aws:PrincipalArn condition

Permissions Boundary Role Policy Resource Policy Result
- - Allow Deny
- Allow Allow Deny
Allow Allow - Allow
Allow - Allow Deny
Allow Allow Allow Allow
Allow - - Deny
- Allow - Deny

"*" as resource policy principal, with role in aws:PrincipalArn condition

Permissions Boundary Role Policy Resource Policy Result
- - Allow Allow
- Allow Allow Allow
Allow Allow - Allow
Allow - Allow Allow
Allow Allow Allow Allow
Allow - - Deny
- Allow - Deny

The code in this repo verifies this.

Install pipenv if you haven't got it. Run pipenv install and then test.py. Use --profile on test.py to make it use a config profile.

This will create a stack named permissions-boundary-test with a role, and managed policy (for the role's permissions boundary), and an S3 bucket. It will run the tests against the stack using the role as the principal in the bucket policy, and then create an assumed role session, update the stack to use the assumed role session as the principal in the bucket policy, and run the tests.

About

Demonstration that AWS IAM policy evaluation docs are incorrect

License:Apache License 2.0


Languages

Language:Python 100.0%