This is a follow-on blog to Practical Application of AWS Tags. In this blog, we will see how Tags can be used to create flexible Identity Access Management (IAM) Policies based on simple Tags. These flexible IAM Policies can be applied across any AWS Account without modification.

Flexibility of Tags

AWS Tags are extremely flexible. As long as you adhere to the AWS Tagging Syntax, it is possible to create Tags to describe a User, Project or even geographic location. Once these tags are applied consistently across the AWS Resources, you are now in a position to build flexible Identity Access Management (IAM) Policies across your accounts based on your tagging policy.

As long as your tagging policy is enforced, IAM access policies can to Allow or Deny access to AWS Resources or IAM Roles can be expressed by a few simple AWS Tags, e.g., “Project” and “Department”.

Use Case: Restrict Actions on AWS Resources

Here’s a simple example from the AWS documentation:

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_ec2-start-stop-tags.html: How To Secure AWS Resources with AWS Tags

            "Sid": "StartStopIfTags",
            "Effect": "Allow",
            "Action": [
                "ec2:StartInstances",
                "ec2:StopInstances"
            ],
            "Resource": "arn:aws:ec2:<region>:<account-id>:instance/*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/Project": "DataAnalytics",
                    "aws:PrincipalTag/Department": "Data"
                }
            }

As you can see, this IAM Policy is based off the definition of two Tags: Project and Department. Furthermore, let’s assume the above IAM Policy is only attached IAM Roles used by developers in the Data Department.

With these two simple Tags, it is possible to enforce an IAM Policy for the Data Department. The members of the Data Department could only Stop and Start Data Analytics instances. This IAM Policy would not allow members of the Data Department to Stop and Start any other EC2 Instances in the account, even if they were other instances used for other Data Projects!

Use Case: Restrict Access to other Accounts using Tags

In AWS IAM, the action of accessing another IAM Role in another account is known as AssumeRole or sts:AssumeRole. As you can imagine, it is very important to control how one IAM Role can take on the persona of another IAM Role a different account.

The following is an example of how you only let certain IAM Users or IAM Roles access an IAM Role in a Destination account. This example is based off attaching the Project Tag to the User (or Role) which is trying to execute the AssumeRole.

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_iam-assume-tagged-role.html: How To Secure AWS Resources with AWS Tags

NOTE: The code below is loosely based off the above link. It has been modified to demonstrate cross-account access.

            "Sid": "AssumeTaggedRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Principal": {
               "AWS": "arn:aws:iam::<destination-account>:<destination-account-role>"
            },
            "Condition": {
                "StringEquals": {"iam:ResourceTag/Project": "ExampleCorpABC"}
            }

The above IAM Policy snippet ensure that only Users and Roles of ExampleCorpABC can assume the Destination Role in the Destination Account.

As you can see, tagging IAM Users and IAM Roles, you can create IAM Policies to control how that entity access other AWS Accounts.

Note of Caution: Protect Modification to AWS Tags

As you can see, a few simple Tags like Project and Department can have a big affect on your IAM Policies, and therefore your overall Security posture. By implementing IAM Security with AWS Tags, these Tags now become an enforcement mechanism and must be protected.

If AWS Tags are used in IAM Policies, then the ability to add, modify or remove of Tags must be Logged, tightly Controlled and Audited. If an attacker has the ability to modify AWS Tags, then they have the ability to gain more access to AWS Resources.

Final Thoughts

As your AWS footprint grows, security will always be a concern. AWS Tags are a great way to create flexible security policies which do not require modification with the addition of a team or a new project.

However, since AWS Tags are an integral part of your security posture, they must be regulated and monitored to ensure security and compliance.