AWS IAM: Resource Based Policies
One of the trickiest topics in AWS is Identity and Access Management. You’re always wondering which service requires which permissions to access another service, and if the policies that you have attached to their roles are secure enough and in agreement with security best practices.
Things can get even trickier when you realize that there are situations when your service can actually access another service, even though you have not attached a policy to it which enables this.
One of the most common reasons for this is the resource based policy.
When you are granting a service permissions to communicate with another service, you are most likely doing this by assigning an identity based policy to it. For example, if you have an EC2 instance that needs to access an S3 bucket, you need to modify the IAM role of the EC2 instance and attach a identity based policy that allows access to this specific S3 bucket.
You can however give access to the EC2 on the S3 bucket side, by creating a resource based policy. In the case of S3, this is also known as a bucket policy, but not all resource based policies are bucket policies.
Resource based policies can also grant access not only to services, but to certain users. This can be useful if, for example, you have an S3 bucket, but want certain files in the bucket to be available only to administrators and hidden away from other users.
A resource based policy, unlike it’s identity based counterpart, requires a Principal element located inside the Statement element of the policy, which specifies which entity will be granted access. Here’s an example of a resource based policy:
From this policy we can observe that the principal is an AWS account with the ID 111122223333. We can also see that the resource allowing access is an SQS queue called app1queue. A condition for accessing also exists, declaring that there is a certain time frame for which this access is valid. This, in total, means that all services from AWS account 111122223333 are granted access to this SQS queue from January 30th 2022 until March 30th 2022. These services now do not require an identity based policy to access this queue.
Resource based policies can be useful for granting access to other AWS accounts to your resources. You could change the account ID in the principal field, and now the services from that AWS account would have access to this particular SQS queue.
Although resource based policies can indeed come in handy, one of their main drawbacks is that they are not available for all AWS services.
You can find a list of all services that support resource based policies here.
Confusion can often arise when an identity based policy declares permissions that are opposite to a resource based policies permissions. The main thing to remember there, is that an explicit deny, always outweighs an explicit allow. To read more about IAM policy evaluation logic, I recommend looking at this AWS documentation.
The main thing to remember is that resource based policies can very often be the reason why your services are granted (or denied) access to another service, even though their identity based policy might not specify this behavior.
That’s all for this article. I hope this cleared up some confusion about AWS IAM that you may have had. Learning about resource based policies certainly helped me solve some of my cloud headaches.
Thanks for reading!
