Create an IAM Policy that allows everything except IAM except PassRole

amazon ec2amazon-iamamazon-web-services

I'm attempting to modify an IAM Policy so that users can associate an IAM Role with EC2 instances that allows Read Only rights to our S3 buckets.

Our teams do quite a bit of R&D with AWS, and so I'm loathe to restrict access to any AWS services except for IAM, which would allow escalation of privileges.

I've used the information in this question to add the iam:PassRole, but the policy fails to validate in the simulator.

{
"Statement": [
    {
        "Effect": "Allow",
        "NotAction": "iam:*",
        "Resource": "*"
    },
    {
        "Effect": "Allow",
        "Action": "iam:PassRole",
        "Resource": "arn:aws:iam::ACCOUNTID:role/MYROLE"
    }
]
}

If I change the Resource of the second statement to "Resource": "*" validation succeeds and the simulator shows that PassRole is explicitly allowed, everything else in IAM is implicitly denied, and everything in S3 is explicitly allowed.

What am I doing wrong with the named role?
What could the security implications be by allowing PassRole for all (I'm assuming the policy simulator isn't fibbing).
Is there a better way to achieve what I want?

Best Answer

To me, this seems likes a bug in the Policy Simulator. Even Amazon themselves declares a policy just like yours in an example of theirs. The simulator complains, but actually attaching this policy to a user works out fine.

What am I doing wrong with the named role?

To the best of my knowledge, nothing.

What could the security implications be by allowing PassRole for all (I'm assuming the policy simulator isn't fibbing).

Well, you'd be allowing the iam:PassRole action for any role. That basically means that a user with this policy would be able to launch an EC2 instance with any IAM role attached to it. It's also explained in the AWS documentation I linked above:

Alternatively, you could grant IAM users access to all your roles by specifying the resource as "*" in this policy. However, consider whether users who launch instances with your roles (ones that exist or that you'll create later on) might be granted permissions that they don't need or shouldn't have.