Quick Guide on How AWS Service Control Policy Inheritance Work
AWS SCP inheritance work slightly different than other policies
Published Oct 27, 2024
AWS Service Control Policies (SCP) are higher level of policies which you can deploy through the AWS Organization to control the AWS Services in your AWS Accounts. It gives a central control over permissions otherwise provisioned through the AWS IAM. AWS SCP will be having explicit actions on your account either Allow or Deny based on the method of how you need to enforce control over your AWS Accounts.
How AWS Service Control Policies work with Inheritance differs depending on whether it's an allow or deny policy.
If the SCP is an allow policy, the allowed policy should be attached/mentioned in every level of the path to the AWS account including the account itself. If a particular allowed service is not mentioned in a certain level, in the AWS Account hierarchy, that service will not be allowed.
Let’s see an example below.
In the diagram you can see 5 SCPs attached to the accounts and OUs. Let's see what permissions are allowed by each SCP.
- SCP 1 provides full access to All AWS Service.
- SCP 2 provides full access to the AWS EC2, S3 and RDS Services.
- SCP 3 provides full access to the AWS EC2 and S3 Services.
- SCP 4 provides full access to the AWS S3 Service.
- SCP 5 provides full access to the AWS SNS Service.
- SCP 6 provides full access to the AWS RDS Service.
The diagram above shows where each SCP is attached. Let's consider AWS Accounts A, B, C and D. Below table show which AWS Services are finally allowed in each above-mentioned AWS Accounts, based on the how Allow SCP inheritance work.
| Account Name | Allowed AWS Services |
|---|---|
| Account A | AWS S3 |
| Account B | AWS EC2, AWS RDS, AWS S3 |
| Account C | No AWS Services |
| Account D | All AWS Services |
Let's analyze …...
- Account A only has access to AWS S3 service as it is the only AWS service allowed in each level of the attached SCPs. All the other Services that have been mentioned was removed in subsequent upper levels leading to the account.
- For Account B, the services AWS EC2, AWS S3, and AWS RDS is allowed as those services are consistently mentioned in each level throughout the account’s hierarchy.
- For Account C, No AWS Services are permitted as the attached SCPs throughout the hierarchy do not have any consistent permission mentioned. At the Root OU level and Dev OU level “All AWS Services” are permitted. But in App 1 OU level, only AWS SNS service was permitted. Thus, at that level only AWS SNS was allowed in the hierarchy (Since all services by default includes SNS). But at the last level, which is the account level, a different permission is allowed which is RDS Service. Although this service was allowed on the Root OU and the Dev OU level, it was not allowed on the App 1 OU which is the 3rd level in the account hierarchy path. And the AWS SNS service which was allowed at the Account C’s hierarchy path up until 3rd level, is not allowed at the account level attached SCP. As a result, not service is allowed in the AWS Account C.
- In Account D, all services are allowed as the “All AWS Services” are allowed in each SCP attached throughout each level in the account’s hierarchy. On thing to note here is that, although I have shown as attaching the same SCP at each level, the SCP name can be different. Only the permissions mentioned should be the same.
Hope above clarifies on how the AWS SCP’s inheritance work when the Effect is “Allow”.
If it's a Deny based SCP, regardless of the level the SCP is attached all the AWS Accounts in its pathway downwards will deny the services/actions mentioned in the SCP regardless of whether there are any allow statements allowing the service at every level. This is due to how policies (Policy Effect Precedence) work in AWS. Deny statements always get the precedence over any allow statements.
Let’s consider the scenario below.
In the above scenario, 4 SCPs are attached to the AWS Accounts and OUs. Let's see the contents defined in each SCP.
- SCP 1 provides full access to All AWS Service.
- SCP 2 denies AWS EC2, S3 and RDS Services.
- SCP 3 denies AWS CloudWatch Service.
- SCP 4 denies AWS SNS Service.
The diagram above shows where each SCP is attached. Let’s consider AWS Accounts A, B, C and D again and see how AWS Services will behave. Below table show which AWS Services are finally allowed and denied in each above-mentioned AWS Accounts, based on the how Allow and Deny SCP inheritance work.
| Account Name | Allowed AWS Services |
|---|---|
| Account A | All AWS Services Except EC2, S3 and RDS |
| Account B | AWS AWS Services Except EC2, S3, RDS and CloudWatch |
| Account C | AWS AWS Services Except SNS |
| Account D | All AWS Services |
Again, Let’s analyze and what has happened ……...
- Since SCP 2 is attached in the Prod OU which is in the direct path for the AWS Account A, the services EC2, S3 and RDS have been denied in the AWS Account. Remember, deny SCP does not need to be attached at every level.
- For Account B, apart from the SCP 2 attached in its hierarchy, SCP 3 is attached to Account B directly. Thus, apart from the services mentioned in SCP 2, the AWS CloudWatch Service mentioned in the SCP 3 also denied access in the AWS Account B.
- There is only one Deny SCP attached in the AWS Account C’s hierarchy which is SCP 4 attached at the APP1 OU under the Dev OU. This SCP denies the SNS only, thus making the Account C users deny using AWS SNS Service. Again, remember the Deny SCP can be attached at any level and the effect will be the same, it denies the mentioned services.
- AWS Account D has all its services allowed as no SCP attached directly or in its hierarchy denies any services.
I hope the above two scenarios we discussed about Allow and Deny SCPs and how they work clears the behavior and what to consider when using SCPs to control and secure the access to AWS Services within your AWS Accounts.
If you look at the AWS Organizations in your AWS Account, under Policies → Service Control Policies, you’ll be able to see a policy named “FullAWSAccess” and inside the targets tab, you can see its attached to your AWS Account. You can see this is you have enabled the AWS Organizations (There is no additional cost for enabling the AWS Organizations). If this SCP was not attached to your AWS Account, you will not be able to access any AWS Service regardless of the AWS User Account type you are using (IAM/Federated/SSO/Root).
Below is an illustration of how AWS Account’s SCP attachment will look like by default.
- In order to use AWS Service Control Policies, you need to have AWS Organizations enabled.
- SCPs needs to be enabled in the AWS Organizations → Policies Section.
- AWS Service Control Policies will not work or prevent actions allowed through the AWS Resource Policies or AWS Service Linked Roles. Using the AWS SCPs you can only control AWS IAM policies whether they are attached to a User, Group or Role. Since AWS Identity Center also uses AWS Roles underneath to provide actual permissions, this applies to permissions given through AWS Identity Center Permission Sets.
- SCPs cannot be self-attached. When your AWS Account is attached to an AWS Organization, the SCPs can only be attached from the AWS Management Account of the AWS Organization. But you cannot attach SCPs to your Management Account, other than the default attached SCP. This is being done as a safety mechanism to avoid any accidental incorrect SCPs being attached to the Management Account so that it will lose the complete or the needed access to Manage the entire AWS Organization. Even though you attach a SCP to Root OU, the actions in the SCP will have no effect in the Management Account.
- That means, if you have only one AWS Account in your AWS Organizations you cannot use the AWS SCP to control its services as that account is the AWS Organizations Management Account.
- Think twice when creating/designing the AWS SCP and where should you attach that.
- AWS SCPs take precedence over all the other AWS Policy types such as IAM Policies, AWS SSO Permission Sets, AWS IAM Permission Boundaries.
AWS Service Control Policies are a strong service that you can use to Control the access to your AWS Services and the actions that can be performed in the account by users (IAM/SSO) or even by other AWS Services. It even can control the actions performed by the Root User itself. With this strong security control comes with great responsibility. When you are creating/designing the AWS SCPs you need to think on how it will behave and impact the existing operations. So as a general rule of thumb (Good Practice), before attaching any newly created SCP to a Production Account, test them on test/dev accounts or OUs.
I hope you all got a good idea about AWS SCPs, types of AWS SCPs and how the inheritance of AWS SCPs work. Hope this article has helped you in your Cloud Journey. If you wish to read and learn in depth, please follow the AWS Official Documentation here.