4. AWS Organizations and Control Tower

Explore

AWS Organizations

Managing access permissions for your AWS organization

All AWS resources, including the roots, OUs, accounts, and policies in an organization, are owned by an AWS account, and permissions to create or access a resource are governed by permissions policies. For an organization, its management account owns all resources. An account administrator can control access to AWS resources by attaching permissions policies to IAM identities (users, groups, and roles).

When granting permissions, you decide who is getting the permissions, the resources that they get permissions for, and the specific actions that you want to allow on those resources.

By default, IAM users, groups, and roles have no permissions. As an administrator in the management account of an organization, you can perform administrative tasks or delegate administrator permissions to other IAM users or roles in the management account. To do this, you attach an IAM permissions policy to an IAM user, group, or role. By default, a user has no permissions at all; this is sometimes called an implicit deny. The policy overrides the implicit deny with an explicit allow that specifies which actions the user can perform, and which resources they can perform the actions on. If the permissions are granted to a role, users in other accounts in the organization can assume that role.

AWS Organizations resources and operations

This section discusses how AWS Organizations concepts map to their IAM-equivalent concepts.

Resources

In AWS Organizations, you can control access to the following resources:

The root and the OUs that make up the hierarchical structure of an organization

The accounts that are members of the organization

The policies that you attach to the entities in the organization

The handshakes that you use to change the state of the organization

Each of these resources has a unique Amazon Resource Name (ARN) associated with it. You control access to a resource by specifying its ARN in the Resource element of an IAM permission policy. For a complete list of the ARN formats for resources that are used in AWS Organizations, see

Resources types defined by AWS Organizations⁠

in the Service Authorization Reference.

Operations

AWS provides a set of operations to work with the resources in an organization. They enable you to do things like create, list, modify, access the contents of, and delete resources. Most operations can be referenced in the Action element of an IAM policy to control who can use that operation. For a list of AWS Organizations operations that can be used as permissions in an IAM policy, see

Actions defined by AWS Organizations⁠

in the Service Authorization Reference.

When you combine an Action and a Resource in a single permission policy Statement, you control exactly which resources that particular set of actions can be used on.

Condition keys

AWS provides condition keys that you can query to provide more granular control over certain actions. You can reference these condition keys in the Condition element of an IAM policy to specify the additional circumstances that must be met for the statement to be considered a match.

The following condition keys are especially useful with AWS Organizations:

aws:PrincipalOrgID – Simplifies specifying the Principal element in a resource-based policy. This global key provides an alternative to listing all the account IDs for all AWS accounts in an organization. Instead of listing all of the accounts that are members of an organization, you can specify the

organization ID⁠

in the Condition element. For more information, see the description of PrincipalOrgID in

AWS global condition context keys⁠

in the IAM User Guide.

Note: This global condition also applies to the management account of an organization.

aws:PrincipalOrgPaths – Use this condition key to match members of a specific organization root, an OU, or its children. The aws:PrincipalOrgPaths condition key returns true when the principal (root user, IAM user, or role) making the request is in the specified organization path. A path is a text representation of the structure of an AWS Organizations entity. For more information about paths, see

Understand the AWS Organizations entity path⁠

in the IAM User Guide. For more information about using this condition key, see

aws:PrincipalOrgPaths⁠

in the IAM User Guide.

For example, the following condition element matches for members of either of two OUs in the same organization.

"Condition": {

"ForAnyValue:StringLike": {

"aws:PrincipalOrgPaths": [

"o-a1b2c3d4e5/r-f6g7h8i9j0example/ou-def0-awsbbbbb/",

"o-a1b2c3d4e5/r-f6g7h8i9j0example/ou-jkl0-awsddddd/"

]

}

organizations:PolicyType – You can use this condition key to restrict the Organizations policy-related API operations to work on only Organizations policies of the specified type. You can apply this condition key to any policy statement that includes an action that interacts with Organizations policies.

You can use the following values with this condition key:

AISERVICES_OPT_OUT_POLICY

BACKUP_POLICY

SERVICE_CONTROL_POLICY

TAG_POLICY

For example, the following example policy allows the user to perform any Organizations operation. However, if the user performs an operation that takes a policy argument, the operation is allowed only if the specified policy is a tagging policy. The operation fails if the user specifies any other type of policy.

{

"Version": "2012-10-17",

"Statement": [

{

"Sid": "IfTaggingAPIThenAllowOnOnlyTaggingPolicies",

"Effect": "Allow",

"Action": "organizations:*",

"Resource": "*",

"Condition": {

"StringLikeIfExists": {

"organizations:PolicyType": [ "TAG_POLICY" ]

}

]

}

organizations:ServicePrincipal – Available as a condition if you use the

EnableAWSServiceAccess⁠

DisableAWSServiceAccess⁠

operations to enable or disable

trusted access⁠

with other AWS services. You can use organizations:ServicePrincipal to restrict requests that those operations make to a list of approved service principal names.

For example, the following policy allows the user to specify only AWS Firewall Manager when enabling and disabling trusted access with AWS Organizations.

{

"Version": "2012-10-17",

"Statement": [

{

"Sid": "AllowOnlyAWSFirewallIntegration",

"Effect": "Allow",

"Action": [

"organizations:EnableAWSServiceAccess",

"organizations:DisableAWSServiceAccess"

"Resource": "*",

"Condition": {

"StringLikeIfExists": {

"organizations:ServicePrincipal": [ "fms.amazonaws.com" ]

}

]

}

For a list of all of the AWS Organizations–specific condition keys that can be used as permissions in an IAM policy, see

Condition keys for AWS Organizations⁠

in the Service Authorization Reference.

⁠

Understanding resource ownership

The AWS account owns the resources that are created in the account, regardless of who created the resources. Specifically, the resource owner is the AWS account of the

principal entity⁠

(that is, the root user, an IAM user, or an IAM role) that authenticates the resource creation request. For an AWS organization, that is always the management account. You can't call most operations that create or access organization resources from the member accounts. The following examples illustrate how this works:

If you use the root account credentials of your management account to create an OU, your management account is the owner of the resource. (In AWS Organizations, the resource is the OU.)

If you create an IAM user in your management account and grant permissions to create an OU to that user, the user can create an OU. However, the management account, to which the user belongs, owns the OU resource.

If you create an IAM role in your management account with permissions to create an OU, anyone who can assume the role can create an OU. The management account, to which the role (not the assuming user) belongs, owns the OU resource.

⁠

Managing access to resources

A permissions policy describes who has access to what. The following section explains the available options for creating permissions policies.

Note

This section discusses using IAM in the context of AWS Organizations. It doesn't provide detailed information about the IAM service. For complete IAM documentation, see the

IAM User Guide⁠

. For information about IAM policy syntax and descriptions, see the

IAM JSON policy reference⁠

in the IAM User Guide.

Policies that are attached to an IAM identity are referred to as identity-based policies (IAM policies). Policies that are attached to a resource are referred to as resource-based policies. AWS Organizations supports only identity-based policies (IAM policies).

Topics

⁠

Identity-based permission policies (IAM policies)⁠

⁠

Resource-based policies⁠

⁠

Identity-based permission policies (IAM policies)

You can attach policies to IAM identities to allow those identities to perform operations on AWS resources. For example, you can do the following:

Attach a permissions policy to a user or a group in your account – To grant a user permissions to create an AWS Organizations resource, such as a

service control policy (SCP)⁠

or an OU, you can attach a permissions policy to a user or a group that the user belongs to. The user or group must be in the organization's management account.

Attach a permissions policy to a role (grant cross-account permissions) – You can attach an identity-based permissions policy to an IAM role to grant cross-account access to an organization. For example, the administrator in the management account can create a role to grant cross-account permissions to a user in a member account as follows:

The management account administrator creates an IAM role and attaches a permissions policy to the role that grants permissions to the organization's resources.

The management account administrator attaches a trust policy to the role that identifies the member account ID as the Principal who can assume the role.

The member account administrator can then delegate permissions to assume the role to any users in the member account. Doing this allows users in the member account to create or access resources in the management account and the organization. The principal in the trust policy can also be an AWS service principal if you want to grant permissions to an AWS service to assume the role.

For more information about using IAM to delegate permissions, see

Access Management⁠

in the IAM User Guide.

The following are examples of policies that allows a user to perform the CreateAccount action in your organization.

{

"Version":"2012-10-17",

"Statement":[

{

"Sid":"Stmt1OrgPermissions",

"Effect":"Allow",

"Action":[

"organizations:CreateAccount"

"Resource":"*"

}

]

}

You can also provide a partial ARN in the Resource element of the policy to indicate the type of resource.

{

"Version":"2012-10-17",

"Statement":[

{

"Sid":"AllowCreatingAccountsOnResource",

"Effect":"Allow",

"Action":"organizations:CreateAccount",

"Resource":"arn:aws:organizations::*:account/*"

}

]

}

You can also deny the creation of accounts that do not include specific tags to the account being created.

{

"Version":"2012-10-17",

"Statement":[

{

"Sid":"DenyCreatingAccountsOnResourceBasedOnTag",

"Effect":"Deny",

"Action":"organizations:CreateAccount",

"Resource":"*",

"Condition":{

"StringEquals":{

"aws:ResourceTag/key":"value"

}

]

}

For more information about users, groups, roles, and permissions, see

IAM identities (users, user groups, and roles)⁠

in the IAM User Guide.

Resource-based policies

Some services, such as Amazon S3, support resource-based permissions policies. For example, you can attach a policy to an Amazon S3 bucket to manage access permissions to that bucket. AWS Organizations currently doesn't support resource-based policies.

⁠

Loading docs.aws.amazon.com⁠

⁠

AWS Organizations resources and operations

Resources

Operations

Condition keys

Understanding resource ownership

Managing access to resources

Topics

Identity-based permission policies (IAM policies)

Resource-based policies

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.