Recently, AWS introduced the capability to use tags on IAM principals (users and roles). This feature significantly simplifies the process of granting access to your resources, allowing you to create a single policy that governs access to various resources without the need to modify it for each new addition. Essentially, this enables attribute-based access control (ABAC), streamlining permissions management at scale. Administrators can now develop a reusable policy that provides permissions based on the attributes of the IAM principal, such as tags. For instance, as an admin, you can establish a single IAM policy that permits your developers to access AWS resources corresponding to their project tags. As developers add resources to their projects, the appropriate permissions are automatically applied based on these attributes, eliminating the need for policy updates for every new resource. This method saves time for you and your team while enhancing security through more granular permission rules.
In this article, I will provide three examples of how you can manage access permissions using tags on IAM principals and AWS resources. It’s crucial to note that while tags can control access to your AWS resources, this is only applicable if the specific AWS service supports tag-based permissions. For further details on AWS services that support this feature, check out this blog post.
As a reminder, I previously introduced several tagging condition keys that can be used to tailor policies for permissions, limiting their actions and resources.
Condition Key | Description | Supported Actions |
---|---|---|
aws:RequestTag | Tags that are requested to be added or removed. | iam:CreateUser, iam:CreateRole, iam:TagRole, iam:UntagRole, iam:TagUser, iam:UntagUser |
aws:TagKeys | Tag keys that are verified before actions are executed. | iam:CreateUser, iam:CreateRole, iam:TagRole, iam:UntagRole, iam:TagUser, iam:UntagUser |
aws:PrincipalTag | Tags associated with the user or role making the request. | This is a global condition (applies to all actions across all services). |
iam:ResourceTag | Tags associated with an IAM resource. | All IAM APIs that support an IAM user or role and sts:AssumeRole. |
Example 1: Granting IAM Users Access Based on Tags
Consider a scenario where multiple developer teams require permission to start and stop certain EC2 instances based on their cost center. In the following policy, I define the EC2 actions ec2:StartInstances
and ec2:StopInstances
in the Action element and allow access to all resources in the Resource element. The Condition element leverages the aws:PrincipalTag
to ensure that the user can only start and stop an instance if the value of the CostCenter
tag on the instance matches that of the user. By attaching this policy to your developer roles or groups, you simplify permission management, requiring only a single policy for all dev teams.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:StartInstances",
"ec2:StopInstances"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/CostCenter": "${aws:PrincipalTag/CostCenter}"
}
}
}
]
}
Example 2: Granting Group Access to AWS Resources Using Tags
Suppose you have database administrators who need to start, stop, and reboot specific Amazon RDS instances. In the policy below, I specify the actions for Amazon RDS and use the aws:PrincipalTag
condition to allow access only to users tagged with CostCenter=0735
. I also control access to databases tagged with Project=DataAnalytics
. By attaching this policy to an IAM group containing all database administrators, any member tagged with CostCenter=0735
gains access to the RDS instance tagged with Project=DataAnalytics
.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "rds:DescribeDBInstances",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"rds:RebootDBInstance",
"rds:StartDBInstance",
"rds:StopDBInstance"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/CostCenter": "0735",
"rds:db-tag/Project": "DataAnalytics"
}
}
}
]
}
Example 3: Using Tags to Control Access to IAM Roles
Imagine a user, Sarah in Account A, who needs to manage several applications and assume specific roles in Account B. The policy below allows Sarah’s IAM user permissions to assume roles tagged with ExampleCorpABC
. The Action element specifies sts:AssumeRole
, granting permission to assume roles. The Resource element uses a wildcard (*) for all roles but restricts access through the iam:ResourceTag
condition. This ensures Sarah can only assume roles tagged with Project=ExampleCorpABC
, thus maintaining control.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "*",
"Condition": {
"StringEquals":
{"iam:ResourceTag/Project": "ExampleCorpABC"}
}
}
]
}
In Summary
You can now utilize tags on your IAM principals to effectively manage access to AWS resources, as demonstrated in the three examples provided in this post. For more insights on managing AWS access, consider visiting this authoritative source, or explore this excellent resource for additional information.
Leave a Reply