AWS IAM Policy Types and How To Use Them
When developing your access control strategy for your cloud environment the goal should be to provide least privilege access while making it easy to audit access across your environment. With so many different options and ways that things could go wrong, it’s important to have a plan for how to organize your access control policies in AWS.
There are 4 places where access control policies can be applied:
AWS Organizations Service Control Policies (SCPs),
AWS Identity and Access Management (IAM) permission policies,
resource policies,
and access point policies.
Here is the model I use when deciding where to place a particular access control in AWS.
AWS Organizations Service Control Policies (SCPs)
AWS Organizations is a service that allows you to consolidate billing and centrally manage your AWS accounts. The service allows for the creation of service control policies (SCPs) in order to manage the maximum permissions that your organizational units (OUs), a group of AWS accounts, can have.
A common strategy, and my preferred, for using SCPs is to whitelist any AWS services that you have certified for use within your organization. The SCP to enable this strategy would look like the below example where we’re whitelisting DynamoDB, EC2, and S3:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:*",
"ec2:*",
"s3:*",
],
"Resource": "*"
}
]
}
SCPs can also be used to deny any API actions that would be dangerous in your AWS accounts. For example, you can use SCPs to prevent disabling CloudTrail in your AWS accounts using a policy like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "cloudtrail:StopLogging",
"Resource": "*"
}
]
}
These resources provide example SCPs you can use in your environment:
AWS IAM Identity Policies
AWS allows for attaching access control policies to identities (e.g. roles, users, or groups of users) or resources. Policies that are attached to identities are usually referred to as IAM identity policies.
A common strategy for identity policies is to use tags on your identities to enforce access control to your resources following specific naming conventions or tags. This is particularly important in AWS accounts that are shared across multiple applications (e.g. multi-tenant account). For example, in if you want to make sure that roles for your applications can only access S3 buckets that belong to them you can write a policy like the following:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::${aws:PrincipalTag/ApplicationName}*"
}
]
}
In addition to the policy above you need to tag your application roles with the “ApplicationName” tag. This way, your application’s identities would only be able to get/put objects into S3 buckets which are prefixed with the application’s name.
These resources provide additional guidance on how to follow this strategy for access control:
Simplify granting access to your AWS resources by using tags on AWS IAM users and roles
Tutorial: Using Tags for Attribute-Based Access Control in AWS
AWS IAM Resource Policies
Resource policies are policies attached to AWS resources to individually control access to the resource. There are many resources in AWS that support resource policies such as: SQS queues, KMS keys, and S3 buckets.
Resource policies can be useful when sharing resources across multiple applications or with separate AWS accounts. They can also be dangerous as they could allow accidental exposure of your resource to AWS accounts outside of your control.
Here’s an example of using an SQS resource policy to allow a role in a different account to send messages to the SQS queue:
{
"Version": "2012-10-17",
"Id": "Queue1_Policy_UUID",
"Statement": [{
"Sid":"Queue1_AllActions",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/role1"
]
},
"Action": "sqs:SendMessage",
"Resource": "arn:aws:sqs:us-east-2:444455556666:sharedqueue"
}]
}
Another thing to note that might not be obvious when you’re first learning about IAM is that resource policies are always considered when AWS evaluates if an identity should have access to a particular API. This means that even if you don’t grant access to a resource in their AWS IAM policies, the identity could get access to the resource if the resource policy allows access.
Access Point Policies
The newest addition to the AWS access control family are access points. Access points are an expansion of resource policies, which are meant to be application specific. These help simplify resource policies for resources shared by multiple applications by allowing you to break them down into access points that are application specific. At the moment these are only supported by S3. I have a more detailed tutorial on how to use access points to secure data lakes here.
Conclusion
Understanding the different ways on how access control can be enforced in AWS is important when developing your access control strategy. Having an idea on where to implement a particular control depending on what’s affected by it can help simplify your policies while.
Policies that affect your whole organization should be applied as SCPs while policies that affect resources or identities within an individual account should be applied in the account as IAM identity policies, resource policies, or access points policies depending on the use case.
