Variables in AWS Access Control Policies

Jeff Wierer, Senior Product Manager on the AWS Identity and Access Management (IAM) team sent along a guest post to introduce a powerful new IAM feature.

— Jeff;

AWS Identity and Access Management (IAM) enables you to create policies that control access to AWS service APIs and resources. Today were extending the AWS access policy language to include support for variables. Policy variables make it easier to create and manage general policies that include individualized access control.

Lets briefly review the structure of policies. AWS policies contain one or more statements that determine the level of access. These statements are made up of four parts: Access (granting or denying) for a Principal (the authenticated entity the policy applies to) on a given Resource subject to certain additional contextual Conditions being true at evaluation time. Please see the key concepts portion of the IAM documentation for more information on these concepts.

Policy variables introduce the ability to create a policy which contains variables that will be dynamically evaluated using context from the authenticated users session. This enables you to define general purpose policies without explicitly listing all the components of the policy. For example, you could restrict a user’s access to a particular user-specific S3 folder or allow those users to manage their own access keys or signing certificates using variable keys such as username.

So what variables are supported? Any of the keys you use to define policy conditions (e.g., AWS Keys, S3 Bucket Keys, or SNS Keys) can now be used as a variable. As part of adding support for policy variables we are also introducing three new keys: aws:username, aws:userid, and aws:principaltype, that can also be used as variables. Using policy variables will help reduce the number of policies necessary to grant individualized access control to AWS resources.

Lets look at two specific use cases.

Enable Users to Access their Home Directory in S3
Lets say you want each of your IAM users to have their own home directory in S3 determined by their username. Prior to policy variables, each user would need a unique user policy where the resource name explicitly contains their username. For example, for an IAM user named Anders, the policy would look like this:

If you have more than one user, then every user would require a similar policy, but with a different resource field. Using a policy variable in the resource field greatly simplifies the process. Now its possible to create a single group policy to achieve the same goal. The following group policy grants all members read and write access to S3 objects only when the prefix contains their username.

When this policy is evaluated, if the context from the service request includes the key “aws:username=jim”, then access will be allowed if the resource the user is trying to access matches “arn:aws:s3:::mybucket/home/jim/*”.

Enable Users to Manage their Credentials
Variable substitution also simplifies allowing users to manage their own credentials. If you have many users, you may find it impractical to create individual policies that allow users to create and rotate their own credentials. With variable substitution, this becomes trivial to implement as a group policy. The following policy permits any IAM user to perform any of the key and certificate related actions on their own credentials.

These are just a couple of examples of how you can use variables in an access control policy. For information about uploading and managing policies, see the Managing IAM Policies section of the IAM Documentation.

– Jeff Wierer