AWS Security Blog
Working backward: From IAM policies and principal tags to standardized names and tags for your AWS resources
February 11, 2021: We updated the tag and instance creation policies for Amazon EC2 to reflect network interface support for attribute-based access control (ABAC). We also added a link to additional sample policies for launching an EC2 instance, and we corrected a condition key “aws:RequestTag/access-zone” to “aws:RequestTag/access-environment”. Amazon ElastiCache now supports names up to 50 characters for cache clusters, but we retained mention of the lower limit in this post for illustrative purposes.
July 5, 2019: We added information about ABAC to the “AWS features used in this approach” section.
When organizations first adopt AWS, they have to make many decisions that will lay the foundation for their future footprint in the cloud. Part of this includes making decisions about the number of AWS accounts you choose to operate, but another fundamental task is constructing practical access control policies so that your application teams can’t affect each other’s resources within the same account. With AWS Identity and Access Management (IAM), you can customize granular access control policies that are appropriate for your organization, helping you follow security best practices such as separation-of-duties and least-privilege. As every organization is different, you’ll need to carefully consider what your cloud security policies are and how they relate to your cloud engineering teams. Things to consider include who should be authorized to perform which actions, how your teams operate with one another, and which IAM mechanisms are suitable for ensuring that only authorized access is allowed.
In this blog post, I’ll show you an approach that works backwards, starting with a set of customer requirements, then utilizing AWS features such as IAM conditions and principal tagging. Combined with an AWS resource naming and tagging strategy, this approach can help you meet your access control objectives. AWS recently enabled tags on IAM principals (users and roles), which allows you to create a single reusable policy that provides access based on the tags of the IAM principal. When you combine this feature with a standardized resource naming and tagging convention, you can craft a set of IAM roles and policies suitable for your organization.
AWS features used in this approach
To follow along, you should have a working knowledge of IAM and tagging, and familiarity with the following concepts:
- IAM principal tags: IAM principals (users and roles) now support tagging. In addition to allowing you to add customizable key-value pairs to principals, these tags also can be used to grant access to resources.
- Attribute-based access control (ABAC): ABAC is a form of access control that allows fine-grained access decisions based on a combination of individual attributes. Tag-based authorization enables you to implement ABAC within your organization and helps you manage permissions at scale.
- Resource tags and IAM conditions: Resource tags are metadata that you can set on an AWS resource. Evaluating resource tags via conditions keys that support tag-based authorization is supported by a growing number of AWS resources and IAM actions. Amazon Elastic Compute Cloud (EC2), Amazon Simple Storage Service (S3), and Amazon Relational Database Service (RDS) are some examples.
- Tag-on-create: Many AWS resources, such as Amazon EC2 and Amazon Elastic Block Store (EBS), support assigning tags at the time of resource creation.
- Amazon Resource Names (ARNs): ARNs are unique identifiers for AWS resources. You can reference ARNs in IAM policies to allow access to resources. Some resources have ARNs based on user-provided names. ARNs can be string matched with wildcards ( * and ?) in IAM policies. Amazon Simple Notification Service (SNS), and Amazon Simple Queue Service (SQS), are examples of resources that currently do not support authorization based on tags but do support resource-level permissions (whose access via IAM can only be controlled by referencing their ARN). A list of services and their support for IAM is listed here.
- IAM permissions boundaries: Permissions boundaries allows you to limit the maximum permissions that a principal can have. They can only be associated with users or roles in a 1:1 relationship.
Introducing Example Corporation
To illustrate the strategies I discuss, I’ll refer to a fictitious customer throughout my post: Example Corporation is a large organization that wants to use their existing Microsoft Active Directory (AD) as their identity store, with Active Directory Federation Services (AD FS) as the means to federate into their AWS accounts. They also have multiple business projects, some of which will need their own AWS accounts, and others that will share AWS accounts due to the dependencies of the applications within those projects. Each project has multiple application teams who do not need to access each other’s AWS resources.
Example Corporation’s access control requirements
Example Corporation doesn’t always dedicate a single AWS account to one team or one environment. Sometimes, multiple project teams work within the same account, and sometimes they have more than one environment in an account. Figure 1 shows how the Website Marketing and Customer Marketing project teams (each of which has multiple application teams) share two AWS accounts: a development and staging AWS account and a production AWS account. Although production has a dedicated AWS account, Example Corporation has decided that a shared development and staging account is acceptable.
Figure 1: AWS accounts shared by Example Corp’s teams
The development and staging environments share an AWS account, and the two teams do work closely together. All projects within an account will be allowed access to the read-only metadata of other resources, such as EC2 instance names, tags, and IAM information. However, each project team wants to prevent their application resources from being modified by the other team’s members.
Initial decisions for supporting shared account access control
Example Corporation decides to continue using their existing identity federation solution for access to AWS, as the existing processes for handling joiners, movers, and leavers can be extended to manage identities within AWS. They will enable this via Security Assertion Markup Language (SAML) provided by ADFS to allow Example Corporation’s AD users to access AWS by assuming IAM roles. Initially, they will create three IAM roles—project administrator, application administrator, and application operator—with additional roles to come later.
The company knows they need to implement access controls through IAM, and they’ve created an initial list of AWS services (EC2, RDS, S3, SNS, and Amazon CloudWatch) to secure. Infrastructure as code (IaC) is a new concept at Example Corporation, so they want to keep initial IAM roles and policies as simple as possible. IAM principal tags will help them reuse standard policies across accounts. Principal tags are global condition keys assigned to a user or role. They can be used within a condition to ensure that a new resource is tagged on creation with a value that matches your principal. They can also be used to verify that an existing resource has a matching tag prior to allowing an action against that resource.
Many, but not all, AWS services support tag-based authorization of AWS resources. For services that don’t support tag-based authorization, Example Corporation will enable access control by utilizing ARN paths with wildcards (ARN matching). The name of the resource and its ARN path will explicitly state which projects, applications, and operators have access to that resource. This will require the company to design and enforce a mandatory naming convention.
Please see the IAM user guide for an up-to-date a list of resources that support tag-based authorization.
Using multiple tags to meet access control requirements
The web and marketing teams have settled on three common roles and have decided their access levels as follows:
- Project administrator: Able to access and modify all resources for a specific project, including all the resources belonging to application teams under the project.
- Application administrator: Able to access and modify only the resources owned by a particular application team.
- Application operator: Able to access and modify only the resources owned by a specific application team, plus those that reside within one of three environments: development, staging, or production.
Figure 2: Example Corp’s teams—administrators and operators with AWS access
As for the principal tags, there will be three unique tags named with the prefix access-, with tag values that differentiate the roles and their resources from other projects, applications, and environments.
Finally, because the AWS account is shared, Example Corporation needs to account for the service usage costs of the two teams. By adding a mandatory tag for “cost center,” they can determine the costs of the web team’s resources versus the marketing team’s resources in AWS Cost Explorer and AWS Cost and Usage Report.
Below is an example of the web team’s tags.
IAM principal tags used for the website project administrator role:
| Tag name | Tag value |
| access-project | web |
| cost-center | 123456 |
Tags for the website application administrator role:
| Tag name | Tag value |
| access-project | web |
| access-application | nginx |
| cost-center | 123456 |
Tags for the website application operator role—specifically for developer access to the dev environment:
| Tag name | Tag value |
| access-project | web |
| access-application | nginx |
| access-environment | dev |
| cost-center | 123456 |
Access control for AWS services and resources that support tag-based authorization
Example Corporation now needs to write IAM policies for their targeted resources. They begin with EC2, as that will be their most widely used service. The IAM documentation for EC2 shows that most write actions (create, modify, delete) support tag-based authorization, allowing the principal to execute the action only if the resource’s tag matches a predefined value.
For example, the following policy statement will only allow EC2 instances to be started or stopped if the resource tag value matches the “web” project name:
However, if Example Corporation uses a policy variable instead of hardcoding the project name, the company can reuse the policy by taking advantage of the aws:PrincipalTag condition key:
Without policy variables, every IAM policy for every project would need a unique value to control access to the resource. Because the text of every policy document would be different, Example Corporation wouldn’t be able to reuse policies from one account to another or from one environment to another. Variables allow them to deploy the same policy file to all of their accounts, while allowing the effect of the policy to differ based on the tags that are used in each account.
As a result, Example Corporation will base the right to manipulate resources like EC2 on resource tags as much as possible. It is important, then, for their teams to tag each resource at the time of creation, if the resource supports it. Untagged resources won’t be manageable, but resources tagged properly will become automatically manageable. The company will use the aws:RequestTag IAM condition key to ensure that the requested access tags and cost allocation tags are assigned at the time of EC2 creation. The IAM policy associated with the application-operator role will therefore be as follows. For a policy sample detailing the minimum set of permissions necessary for the ec2:RunInstances action to succeed, see How can I use IAM policy tags to restrict how an EC2 instance or EBS volume can be created?
If someone tries to create an EC2 instance without setting proper tags, the RunInstances API call will fail. The application-administrator policy will be similar, with the added ability to create a resource in any environment:
And finally, the project-administrator policy will have the most access. Note that even though this policy is for a project administrator, the user is still limited to modifying resources only within three environments. In addition, to ensure that all resources have the required access-application tag, Example Corporation has added a null condition to verify that the tag value is non-empty:
Access control for AWS services and resources without tag-based authorization
Some services don’t support tag-based authorization. In those cases, Example Corporation will use ARN pattern matching. Many AWS resources use ARNs that contain a user-created name. Therefore, the company’s proposal is to name resources following a naming convention. A name will look like: [project]-[application]-[environment]-myresourcename. For resources that are globally unique, such as S3, Example Corporation additionally requires its abbreviated name, “exco,” to be at the beginning of the resource so as to avoid a naming collision with another corporation’s buckets:
To enforce this naming convention, they craft a reusable IAM policy that ensures that only intended users with matching access-project, access-application, and access-environment tag values can modify their resources. In addition, using * wildcard matches, they are able to allow for custom resource name suffixes such as staticassets in the above example. Using an AWS SNS topic as an example, a snippet of the IAM policy associated with the application-operator role will look like this:
And here’s an IAM policy for an application-admin:
And finally, here’s the IAM policy for a project-admin:
The above policies have two caveats, however. First, they require that the principal tags have values that do not include a hyphen, as it is used as a delimiter according to Example Corporation’s new tag-based convention for access control. In addition, a forward slash cannot be used, as it is in use within ARNs by many AWS resources, such as S3 buckets:
It is important that the company doesn’t let users create resources with disallowed or invalid tags. The following application admin permissions boundary policy uses a condition to permit IAM roles to be created, but only if they are tagged appropriately. Please note that these are just snippets of the boundary policy for the sake of illustration:
And likewise, this permissions boundary policy attached to the project admin will do the same:
Note that the above boundary policies can be also be crafted using allow statements and multiple explicit deny statements.
Example Corporation’s resource naming convention requirements
As shown in the above examples, Example Corporation has given project teams the ability to create resources with name-based access control for services that currently do not support tag-based authorization (such as SQS and S3). Through the use of wildcards, teams can still provide custom names to their resources to differentiate from other resources created within the same team.
AWS resources have various limits on the structure and composition of names, so the company restricts the character length on access tags. For example, Amazon ElastiCache cluster names must be 20 alphanumeric characters or less, including hyphens. Most AWS resources have higher character limits, but Example Corporation limits their [project]-[application]-[environment] prefix to a 3-character project ID, 5-character application ID, and 3-character maximum environment name to satisfy their requirements, as this will equal a total of 14 characters (for example, web-nginx-prd-), which leaves 6 characters remaining for the user-specified cluster name.
Summary of Key Decisions
- Services that support tag-based authorization (TBA) must have resources that follow a tagging convention for access control. Tagging on resource creation will be enforced where possible.
- Services that do not support TBA must have resources that follow a naming convention. The cost center tag will still be required and will be applied after resource creation.
- Services that do not support TBA, and cannot have user-specified names in their ARN (less common), will be addressed on a case-by-case basis. They will either need to allow access for all projects and application teams sharing the same account, or allow access via a custom IAM policy created on a case-by-case basis so that only the desired team can access the resource. Each IAM role should leave a few unused slots short of the maximum number of policies allowed per role in order to accommodate custom policies.
- It is acceptable to allow basic List* and Describe* IAM permissions for AWS resources for all users who log in to the account, as the company’s project teams work closely together.
- IAM user and role names created by project and application admins must adhere to the approved resource naming conventions. Admins themselves will have a permissions boundary policy applied to their roles. This policy, in turn, will require that all users and roles the admins create have a permissions boundary policy. This is especially important for roles associated with resources that can potentially create or modify IAM resources, such as EC2 and Lambda.
- Active Directory users who need access to AWS resources must assume different IAM roles in order to utilize the different levels of access that the project admin, application admin, and application operator each provide. Users must also assume a different role if they need access to a different project. This is because each role’s tag has a single value. In this scheme, a single role cannot be assigned to multiple projects or application teams.
Conclusion
Example Corporation was able to allow their project teams to share the same AWS account while still limiting access to a majority of the account’s AWS resources. Through the use of IAM principal tagging, combined with a resource naming and tagging convention, they created a reusable set of IAM policies that restricted access not only between project and application admins and users, but also between different development, stage, and production users.
If you have comments about this post, submit them in the “Comments” section below. If you have questions about or issues implementing this solution, please start a new thread on the IAM forum.
Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.