6

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?

Community
  • 1
Dan Caseley
  • 163
  • 1
  • 4

1 Answers1

3

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.

Bazze
  • 1,511
  • 9
  • 10
  • Excellent answer. Thanks. Since I'm not granting the ability to create Roles, I'll stick with "*". – Dan Caseley Dec 31 '14 at 15:08
  • @Fishbowler this is dangerous if you are not very careful with your role creation. For example, from June 30th, 2015 the EMR service will require that you create and pass it a role that can create and terminate all EC2 instances in an account, read any and all s3 objects, and a ton of other things. If you ever create anything like this, or any administrative role for the purposes of identity federation, etc., you will in the same stroke elevate the permissions of all of your R&D users. – billkw Jun 26 '15 at 18:49