- Newest
- Most votes
- Most comments
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 :-/
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_notresource.html
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.
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
Relevant content
- Accepted Answerasked a year ago
- Accepted Answerasked a year ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 4 months ago
- AWS OFFICIALUpdated 3 months ago
- AWS OFFICIALUpdated a month 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.