Limit scope of AWS Managed IAM Policies?


I have an EC2 instance whose code is deployed to using CodePipeline. For CodeDeploy to be able to operate on the Instance I've attached the AWS managed AmazonEC2RoleforAWSCodeDeploy policy to the instances IAM Role.

The advantage of using the AWS managed policy is that any updates/changes to the CodeDeploy service shouldn't require me to update the instance Role.

However, it's occurred to me that "if" the instance was compromised by an attacker who gained access to the Shell, the unlimited scope of the policy "Resource": "*" would enable the attacker to perform any actions listed in the policy for any of my S3 buckets.

I've been reading about the IAM Permissions Boundary but it seems to be more concerned with limiting policies that can be applied to the Role rather than the Resources they have access to.

So how can I continue to use the AWS managed policy and limit it to specific resources?

3 Answers
Accepted Answer

You could also write your own policy where you "deny everything" and then have NotResource listing of things you need to have access to. This way you could keep using AWS managed policy (to allow access to services and actions) and then attach your own policy to define the scope of it. In reality, this can easily break things so please test it carefully first. In worst case you will also need to define what services and actions your own policy will apply, and effectively rewriting AWS managed policy :-/

profile picture
answered 2 years ago
  • Thanks for that, the "NotResource" is exactly what I was looking for. Now I can continue to use the AWS managed policy while restricting access to the specific bucket.


It is fairly common to use 'Resource': '*' in policies for a role of a resource that executes some actions. If the action is not allowed by the role the action will not even be tried.

The restriction is often in the receiving end of the actions (in this case the S3 bucket). In the bucket policy you can specify exactly who is allowed to do what.

So it makes sense to still use the standard AWS managed policies. If you lookup some terraform modules and look for common managed policy names you will see they are often used with resource '*'.

You could create few other things to restrict access:

  • Boundary Permissions (usually used to prevent users from using any 'forbidden' services)
  • Security Control Policies (usually used in an organisation to disallow certain thing from happening in the member accounts)

Although as said I think in this case it is not necessary.

profile picture
answered 2 years ago

You should consider implementing whats termed "least privilege", allowing only explicitly-specified principals the actions and resources they need to perform their business function and possibly denying access to all other principals.

A great reference for IAM is Effective IAM

answered 2 years ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions