Policy evaluation logic in AWS - Commands & Configuration

Introduction

When you want to control who can do what in your cloud, you use policies. Policy evaluation logic decides if a user is allowed or denied an action based on these policies.

When you want to allow a user to read files from a storage bucket but not delete them

When you want to deny access to a service during certain hours

When you want to combine multiple policies to decide if an action is allowed

When you want to understand why a user was denied access

When you want to test if a policy change will allow or deny an action before applying it

Commands

This command tests if the user 'example-user' is allowed to perform the 's3:GetObject' action according to their policies.

Terminal

aws iam simulate-principal-policy --policy-source-arn arn:aws:iam::123456789012:user/example-user --action-names s3:GetObject

Expected Output

{

    "EvaluationResults": [

        {

            "EvalActionName": "s3:GetObject",

            "EvalResourceName": "*",

            "EvalDecision": "allowed",

            "MatchedStatements": [

                {

                    "SourcePolicyId": "policy1",

                    "StartPosition": {

                        "Line": 3,

                        "Column": 5

                    },

                    "EndPosition": {

                        "Line": 10,

                        "Column": 6

                    }

                }

            ],

            "MissingContextValues": []

        }

    ]

}

→

--policy-source-arn - Specifies the user or role ARN whose policies are evaluated

→

--action-names - Specifies the AWS action to test

This command tests a custom policy defined in 'policy.json' to see if it allows the 's3:DeleteObject' action.

Terminal

aws iam simulate-custom-policy --policy-input-list file://policy.json --action-names s3:DeleteObject

Expected Output

{

    "EvaluationResults": [

        {

            "EvalActionName": "s3:DeleteObject",

            "EvalResourceName": "*",

            "EvalDecision": "explicitDeny",

            "MatchedStatements": [

                {

                    "SourcePolicyId": "customPolicy",

                    "StartPosition": {

                        "Line": 5,

                        "Column": 7

                    },

                    "EndPosition": {

                        "Line": 12,

                        "Column": 8

                    }

                }

            ],

            "MissingContextValues": []

        }

    ]

}

→

--policy-input-list - Specifies the JSON file containing the custom policy

→

--action-names - Specifies the AWS action to test

Key Concept

If you remember nothing else from this pattern, remember: AWS evaluates all policies together and denies access if any policy explicitly denies the action.

Common Mistakes

Testing a policy without specifying the correct action name

The evaluation will not check the intended action and may give misleading results

Always specify the exact AWS action you want to test with --action-names

Assuming that absence of an allow means allow

AWS denies by default if no policy explicitly allows the action

Understand that explicit allow is required; absence of allow means deny

Ignoring explicit deny statements in policies

Explicit deny always overrides allow, causing access to be denied

Check for explicit deny statements carefully when troubleshooting access

Summary

Use 'aws iam simulate-principal-policy' to test user or role permissions for specific actions.

Use 'aws iam simulate-custom-policy' to test standalone policies before applying them.

Remember that explicit deny in any policy overrides all allows during evaluation.