Streamlining Access to AWS Resources Using Tags on IAM Users and Roles

Streamlining Access to AWS Resources Using Tags on IAM Users and RolesMore Info

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.


Comments

Leave a Reply

Your email address will not be published. Required fields are marked *