by José Cegarra, Cloud Engineer

This blog post aims to show how we can get the most out of Service Control Policies (SCPs) in AWS. We will review some tips and tricks that hopefully make your SCPs better and cover some use cases you might find helpful. This blog post is based on SEC201 at AWS re:Invent 2021.

Introduction

Service control policies (SCPs) are a type of organization policy that you can use to manage permissions in your organization. SCPs offer central control over the maximum available permissions for all accounts in your organization. SCPs help you to ensure your accounts stay within your organization’s access control guidelines. SCPs are available only in an organization that has all features enabled. SCPs aren’t available if your organization has enabled only the consolidated billing features.

So, long story short:

  • They can limit the max allowed permissions, but they can’t grant access.
  • They work at the principal level.
  • They can be applied at Account level.
  • They can be applied at OU level.
  • They can be applied at OU root level.
  • They should be used to enforce security invariants- even root accounts can be affected by SCPs.

How to manage maximum limit size in SCP

Image by Author

Be careful with global services/regional services

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyAllOutsideRequestedRegions",
"Effect": "Deny",
"NotAction": [
"cloudfront:*",
"iam:*",
"route53:*",
"support:*"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": [
"eu-west-1"
]
}
}
}
]
}

In other words, this policy means:

[“Deny”] except [“cloudfront:*”,”iam:*”,”route53:*”,”support:*”] for [“all”] the resources, when [“requested region”] is not [“eu-west-1”].

The above policy uses the Deny > Condition Not Like structure that allows you to deny everything except the condition matched.

How do I test my SCPs?

Account -> Staging/Test OU -> Production OU -> root OU (if needed). Bad configurations in SCPs can be very disruptive, so try to reduce the scope of affected accounts.

Image by Author

How do I add exceptions to SCPs?

Let’s take the following example: our company only works on eu-west-1 with some global services, but we need 3rd party services which are deployed in a separate account. Those services need to be deployed cross-region. In this case, instead of having a single SCP under the production OU with thousands of lines — which can be difficult to maintain- we just have another OU called Exceptions with a less restrictive SCP because the other accounts are secure in a separate OU.

Image by Author

Another workaround for exceptions in SCPs is to use tags to allow or deny actions to some principals. This is more useful when focusing on who can do X.

For example, add a tag allow-s3 = true. Then, in the SCP condition, check if the tag is the desired value or not, and if it isn’t, deny the action.

{
"Version": "2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": [
"s3:*"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:PrincipalTag/allow-s3": "true"
}
}
}
}

In other words, this policy means:

[“Deny s3”] for [“all”] the resources, when [“the principal allow-s3 tag”] is not [“true”]

Conclusion

  • test bottom-up when testing your SCPs;
  • not denying global services in the us-east-1 region;
  • adding ghost OUs in case your SCP has reached the limit size; and
  • using a separate OU to add exceptional accounts there.

At Edrans we had rough times writing SCPs, but following these tips & tricks, we have successfully left that behind. More specifically, We had trouble restricting workloads to one specific region without blocking global services (blocking CloudFront, to be more specific). Another real case scenario we faced was a hard time maintaining a large SCP that contained only “Allow” statements, so for each new service released by AWS we had to add it to the SCP, then we realized that using Deny > Condition Not Like structure like shown before covers pretty much everything, but using fewer characters. After all, it is all about keeping it simple.

We are an AWS Premier Consulting Partner company. Since 2009 we’ve been delivering business outcomes and we want to share our experience with you. Enjoy!