How to use Service Control Policies in AWS
Using multiple AWS accounts to provide separation of concerns within a system is a good practice which is increasingly being adopted. This shift has become easier with the introduction of new features which make managing a multi-account system easier.
One of these features is Service Control Policies (SCPs), which makes it easier to apply controls to what accounts in an AWS Organization can do.
SCPs are very similar to IAM policies but with an important conceptual difference. Whereas IAM policies apply to principals within an account (users or roles), SCPs apply to accounts as a whole.
While this may seem like writing IAM policies and SCPs is a duplication of effort, it allows security of accounts as a whole to be delegated to a specific team, while allowing users to create their own IAM policies within those constraints.
When to use SCPs
Because SCPs apply to accounts as a whole they are an important part of a multi-account environment or account vending strategy. By using SCPs you can ensure that an account can only be used for its given purpose by setting guardrails within which IAM entities operate.
SCPs are most useful when combined with Organizational Units, which allow you to define hierarchies of accounts within an Organization.
For example, your business may have multiple SaaS solutions which you provide to your customers. In order to isolate parts of the system from others you have a production and staging account for each product. A simplified account structure may look something like this:
Looking at this account structure, Product 1 may be a system which is deployed to EC2 and makes use of an RDS database. Because this product doesn’t use S3, you’d like to prevent its accounts from accessing S3. On the other hand, Product 2 is a JavaScript application which is deployed to an S3 bucket with a CloudFront distribution. You can use SCPs to enforce different restrictions for each product.
How to use them
In order to use SCPs you first need to enable all features within AWS Organizations. This is a manual step which can be done in the AWS Console.
You should keep in mind that SCPs don’t affect the root account within an Organization. The advantage of this is that you can’t lock yourself out of your Organization because of an overly restrictive policy.
SCPs can be applied either to an individual account or to an Organizational Unit. When there are no policies applied then everything is disabled by default. However, by default AWS applies a policy which allows everything.
When an SCP is applied to an Organizational Unit it is inherited by any OUs or accounts below it in the organization hierarchy. In our example above, we can apply an SCP to the Product 1 OU to deny S3 and the staging and production accounts which be affected by it. Once an action has been explicitly denied it cannot then be allowed by a descendant account.
Some things to consider
As mentioned before, policies can be applied to the root of an Organization but they don’t have any effect on the root account. A good practice would therefore be to provide minimal access to your root account with IAM permissions, using it only to manage the Organization.
There is a limit of 5 SCPs per account or OU and a 5,120 byte limit on the size of each policy. However, similar to IAM policies it’s possible to have multiple statements within a policy. You would therefore need to think about how you combine statements in a single policy to avoid hitting the limit of 5, but without reaching the size limit of a single policy.
Let’s look at some examples
Thinking about the account structure above, we’re going to write some example policies to ensure that our accounts can only be used as we’re expecting them to be.
Service whitelist
Using SCPs we can create a whitelist of allowed services, ensuring that our product accounts can only use the services we intend.
Region whitelist
Let’s assume that we only deploy our SaaS products to the eu-west-1 region. We can use an SCP to ensure that services in other regions can’t be used. Note that we have to use NotAction to ignore services which aren’t region specific.
Deny an action, with an exception
Suppose we want to ensure that in our Product 2 accounts items can only be uploaded to S3 by our deployment pipeline. We might create an SCP similar to the following:
Conclusion
We’ve seen that SCPs are a powerful tool that can be combined with IAM policies to secure a multi-account system in AWS.
By using SCPs you can simplify the process of restricting the actions which can be performed by particular accounts or organizational units in a way that is secure and audit-able.
If you want to understand more about Service Control Policies then a great place to go is the AWS documentation page which includes more policy examples.
I’m a consultant at The Scale Factory, where we empower technology teams to deliver more on the AWS cloud, through consultancy, engineering, support, and training. We might be able to help you too.
