Simplifying permissions management at scale using tags in AWS Organizations

AWS Organizations has extended its existing tagging support for AWS accounts to include all Organizations resources, such as organizational units (OUs) and your root and organization-level policies. You can tag these resources as you create them, giving you a convenient way to make sure that your Organizations resources are categorized from the start, without needing spreadsheets or third-party tools. More importantly, you can now use tags to simplify permissions management at scale in your organization through attribute-based access control (ABAC).

ABAC is an authorization strategy that defines permissions based on user-defined attributes, such as tags, attached to users and AWS resources. ABAC scales seamlessly with your increasing AWS workloads, saving you time and effort in updating and managing permissions policies. In addition, because you’re using attributes in your access policies, you can express permissions at a granular level, improving your organization’s security posture.

In this post, I describe a use case that highlights the benefits of using tags to grant users access to Organizations resources at scale.

Initial context

You can use Organizations OUs to group your accounts into entities that you can then administer by applying policies. For the following use case, you’re the cloud administrator of a corporation that uses Organizations, and you have deployed an OU hierarchy to reflect the geographical distribution of your business units. OUs at the first level represent each of the corporation’s worldwide subsidiaries: North America, Europe, and South America. Under each subsidiary, you have created three OUs, one for each type of workload: Sandbox, Software Development Lifecycle (SDLC), and production environments. The following screenshot shows the resulting configuration.

In this use case, you need to grant access to three members of your team such that each member manages one type of workload (Sandbox, SDLC, or Production) across all subsidiaries. For the purpose of this post, we focus on one of those team members: Márcia Oliveira. You have enabled service control policies (SCPs) at the OU level. As part of her activities, Márcia needs permissions to programmatically list and update the SCPs that are attached to all Production OUs regardless of the subsidiary they belong to.

Attribute-based access control

With ABAC, you can use tags to implement a streamlined way to manage these permissions. You can use tags on both Organizations resources and user entities to create a single tag-based permissions policy that you don’t have to update even as you add new subsidiaries or team members.

Because you’re using tags as the basis of this improved permission-allocation process, you also must make sure that Production OUs are appropriately tagged and no user can untag those OUs after creation.

In summary, to implement ABAC for this use case, you complete the following steps:

1. Tag the existing OUs that you must assign access to.
2. Use the tags to give permissions to Márcia to programmatically list and update the SCPs that are attached to all Production OUs across the organization, regardless of the subsidiary they belong to.
3. Make sure that when new subsidiaries are added, Márcia can perform her tasks on the newly created Production OUs without needing to update the permissions policy.
4. Make sure that new OUs are correctly tagged on creation to ensure your tag-based permissions are always in effect.
5. Prevent users from untagging an OU after it’s created with the correct tag.

Tagging existing OUs

First, you must tag the existing Production OUs to support your permissions scheme. You can accomplish this on the AWS Management Console or using the AWS Command Line Interface (AWS CLI) or SDKs. For this post, we walk through the process using the console.

1. On the Organizations console, on the Organize accounts tab, choose the OU you want to tag.

For this post, we start with the Production OU in the South America subsidiary.

Choose Edit Tags.

2. Create a tag with the key work_type and value production.

3. Repeat this process to tag the other Production OUs in the rest of the subsidiaries in the organization.

Providing permissions based on tags

Now that you have tagged all the OUs, you’re ready to create the AWS Identity and Access Management (IAM) permissions policy to grant Márcia access to list and update the SCPs that are attached to the Production OUs across all subsidiaries. You use the aws:ResourceTag condition key to grant permissions based on the “work_type”:”production” tag you applied to all Production OUs. See the following policy code:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "organizations:UpdatePolicy",
                "organizations:AttachPolicy",
                "organizations:DetachPolicy"
            ],
            "Resource": "*",
            "Condition": {
                "StringLikeIfExists": {
                    "aws:ResourceTag/work_type": "production"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "organizations:ListPoliciesForTarget",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/work_type": "production"
                }
            }
        }
    ]
}

You can attach the preceding policy to a role that Márcia can assume to access the Production OUs. Assuming that your corporation uses a SAML-based identity provider (IdP) to manage corporate user identities, a better alternative is to use your IdP to define and pass session tags. These session tags can be used in the permission policy to grant Márcia access to the Production OUs.

To accomplish this, you can create a single role “work_admins” that all your team members, including Márcia, can assume. Next, you create the “work_role”:”production” attribute for Márcia in your IdP solution and pass those attributes as session tags. You can use this session tag in conjunction with the aws:PrincipalTag condition key in the permission policy and attach the policy to the “work_admins” role. See the following policy code:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "organizations:UpdatePolicy",
                "organizations:AttachPolicy",
                "organizations:DetachPolicy"
            ],
            "Resource": "*",
            "Condition": {
                "StringLikeIfExists": {
                    "aws:ResourceTag/work_type": "production"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "organizations:ListPoliciesForTarget",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/work_type": "production",
                    "aws:PrincipalTag/work_role": "production"
                }
            }
        }
    ]
}

If you reassign Márcia to a new role, all you must do is update her “work_role” attribute in your IdP solution to match the type of workload she will be overseeing.

Ensuring access when adding new OUs

To make sure that Márcia can list and update the SCPs that are attached to all Production OUs even if new ones are created, you can use the new tag-on-create capability in Organizations.

As part of business expansion plans, your corporation must add AWS infrastructure for the newly created Middle East subsidiary. You must provision an OU for the new subsidiary and create all nested OUs for each type of workload, including Production. You can tag the new Production OU as you create it by using tag-on-create, and make sure that Márcia has uninterrupted permissions to the newly created OU.

The following screenshot shows the updated Create organizational unit page on the Organizations console; you have an additional Tags section to add the tags on creation.

The following screenshot shows the newly created OU with its corresponding tag.

Preventing OU creation without the right tags

Your new permission scheme is based on tags, so you want to make sure that OUs are created with the right tags because this impacts how permissions are assigned to your team. You can do so by creating an IAM policy using the aws:RequestTag condition key, which blocks OU creation if they don’t supply the right tags.

The following code snippet shows a sample IAM policy that forces you to use the tag key work_type with three possible values: production, sdlc, and sandbox:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "organizations:CreateOrganizationalUnit",
            "Resource": "*",
            "Condition": {
                "Null": {
                    "aws:RequestTag/work_type": "production"
                }
            }
        },
        {
            "Effect": "Deny",
            "Action": "organizations:CreateOrganizationalUnit",
            "Resource": "*",
            "Condition": {
                "ForAnyValue:StringNotEquals": {
                    "aws:RequestTag/work_type": [
				“production”,
				“sdlc”,
				“sandbox”
			] 
                }
            }
        }
    ]
}

Preventing OU untagging

Finally, you must prevent any unintentional or malicious untagging of Production OUs in your organization. You can do so by denying untagging permissions to all Organizations resources that are tagged with the “work_type”:“production” key-value pair. See the following policy code:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "organizations:UntagResource",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/work_type": "production"
                }
            }
        }
    ]
}

Conclusion

In this post, I showed you how Organizations enables you to use attribute-based access control (ABAC) to simplify managing permissions to your organization’s resources using tags. You can now use ABAC on all your organization’s resources, including accounts, organizational units, and the organization’s root and policies. This allows you to manage permissions to resources that span multiple groupings of an organization’s OU hierarchy. The new tag-on-create feature also enables you to avoid administrative overhead when the OU hierarchy changes. For more information, see the AWS Organizations User Guide.

About the author

Eric is a Senior Technical Product Manager in the AWS Identity team, working on AWS Organizations service core features. Outside of work, Eric enjoys playing basketball and soccer. Eric holds an MBA degree from MIT Sloan.