Inheritance for service control policies - AWS Organizations

Inheritance for service control policies


The information in this section does not apply to management policy types, including AI services opt-out policies, backup policies, or tag policies. See the next section Policy syntax and inheritance for management policy types.

Service control policies (SCPs)

Inheritance for service control policies behaves like a filter through which permissions flow to all parts of the tree below. Imagine that the inverted tree structure of the organization is made of branches that connect from the root to all of the OUs and end at the accounts. All AWS permissions flow into the root of the tree. Those permissions must then flow past the SCPs attached to the root, OUs, and the account to get to the principal (an IAM role or user) making a request. Each SCP can filter the permissions passing through to the levels below it. If an action is blocked by a Deny statement, then all OUs and accounts affected by that SCP are denied access to that action. An SCP at a lower level can't add a permission after it is blocked by an SCP at a higher level. SCPs can only filter; they never add permissions.

SCPs do not support inheritance operators that alter how elements of the policy are inherited by child OUs and accounts.

The following illustration shows how SCPs work.

In this illustration, assume that the oval on the left represents an SCP that is attached to the organization's root. It allows permissions A, B, and C. The root contains an organizational unit (OU) to which is attached a second SCP represented by the oval on the right. That second SCP allows permissions C, D, and E. Because the SCP attached to the root doesn't allow D or E, no OUs or accounts in the organization can use them. Even though the SCP attached to the OU explicitly allows D and E, they are blocked because they're blocked by the SCP attached to the root. Because the OU's SCP doesn't allow A or B, those permissions are blocked for the OU and any of its child OUs or accounts. However, other OUs that might exist under the root can still allow A and B.

As you traverse down the hierarchy of OUs to the account, the process in the previous paragraph is repeated at each OU and finally with the account. At each level, the result of the evaluation at the parent becomes the policy on the left of the diagram and is compared to the SCPs attached to the child OU.

For example, if you were to move down the tree to some child OU called X, imagine that the oval on the left represents the inherited, effective permissions permitted by all of the SCPs above OU X in the hierarchy. The oval on the right represents the SCP attached to an OU or an AWS account contained in OU X. Again, the intersection of those permissions is what is available to be used the entity on the right. If that entity is an AWS account, then the intersection is the set of permissions that can be granted to users and roles in that account. If the entity is an OU, then the intersection is the set of permissions that can be inherited by that OU's children. Repeat the process for each level down the OU hierarchy until you reach the account itself. That final effective policy is the list of permissions that were allowed by every SCP above that account and attached to it.

This means that to allow an AWS service API at the member account level, you must allow that API at every level between the member account and the root of your organization. You must attach SCPs to every level from your organization’s root to the member account that allows the given AWS service API (such as ec2:RunInstances). You can use either of the following strategies for this:

  • A deny list strategy makes use of the FullAWSAccess SCP that is attached by default to every OU and account. This SCP overrides the default implicit deny, and explicitly allows all permissions to flow down from the root to every account, unless you explicitly deny a permission with an additional SCP that you create and attach to the appropriate OU or account. This strategy works because an explicit deny in a policy always overrides any kind of allow. No account below the level of the OU with the deny policy can use the denied API, and there is no way to add the permission back lower in the hierarchy. For more information, see Using SCPs as a deny list.

  • An allow list strategy has you remove the FullAWSAccess SCP that is attached by default to every OU and account. This means that no APIs are permitted anywhere unless you explicitly allow them. To allow a service API to operate in an AWS account, you must create your own SCPs and attach them to the account and every OU above it, up to and including the root. Every SCP in the hierarchy, starting at the root, must explicitly allow the APIs that you want to be usable in the OUs and accounts below it. This strategy works because an explicit allow in an SCP overrides an implicit deny. For more information, see Using SCPs as an allow list.

To review how policies are evaluated in terms of implicit vs. explicit allows and denies, and what overrides what, see Determining whether a request is allowed or denied within an account.

Users and roles in accounts must still be granted permissions using AWS Identity and Access Management (IAM) permission policies attached to them or to groups. The SCPs only determine what permissions are available to be granted by such policies. The user can't perform any actions that the applicable SCPs don't allow. Actions allowed by the SCPs can be used if they are granted to the user or role by one or more IAM permission policies.

When you attach SCPs to the organization root, OUs, or directly to accounts, all policies that affect a given account are evaluated together using the same rules that govern IAM permission policies:

  • Users and roles in affected accounts can't perform any actions that are listed in the SCP's Deny statement. An explicit Deny statement overrides any Allow that other SCPs might grant.

  • Any action that has an explicit Allow in an SCP (such as the default "*" SCP or by any other SCP that calls out a specific service or action) can be delegated to users and roles in the affected accounts.

  • Any action that isn't explicitly allowed by an SCP is implicitly denied and can't be delegated to users or roles in the affected accounts.

By default, an SCP named FullAWSAccess is attached to every organization root, OU, and account. This default SCP allows all actions and all services. So in a new organization, until you start creating or manipulating the SCPs, all of your existing IAM permissions continue to operate as they did. As soon as you apply a new or modified SCP to the organization root or an OU that contains an account, the permissions that your users have in that account become filtered by the SCP. Permissions that used to work might now be denied if they're not allowed by the SCP at every level of the hierarchy down to the specified account.

If you disable the SCP policy type on the organization root, all SCPs are automatically detached from all entities in the organization root. If you reenable SCPs on the organization root, all the original attachments are lost, and all entities are reset to being attached to only the default FullAWSAccess SCP.

For details about the syntax of SCPs, see SCP syntax.

You can see a list of all policies applied to an account and where that policy comes from. To do this, choose an account in the AWS Organizations console. On the account details page, choose Policies and then choose Service Control Policies in the right-hand details pane. The same policy might apply to the account multiple times because the policy can be attached to any or all of the parent containers of the account. The effective policy that applies to the account is the intersection of allowed permissions of all applicable policies.

For more information about how to use SCPs, see Service control policies (SCPs).