Today I’m going to cover off a new feature that was recently announced for AWS Organizations around the use and function of Service Control Policies (SCPs). These new fine-grained controls enabled a wide range of capabilities that have previously been unavailable for customers using a multi-account setup. Previously, when setting up an SCP a user had the option of allowing and denying access to particular Actions within the AWS platform, for example denying access to delete IAM roles. While this does protect AWS Organization dependent resources (such as the role used by AWS Organizations to assume permissions within the account) it also prevented users from deleting all IAM roles.
With the recent feature release, you can now specify Conditions, Resources and NotAction filters to control exactly when and where these permissions are applied. Taking the previous example, using these new controls allows us to specify those precise roles we want to protect. In today’s blog, I’ll walk through how the new controls work and show a couple of examples of how they might be useful.
To get started let’s take a look at an example AWS Organization layout so that we can see where SCP’s will be attached. Below is a screenshot of my current AWS Organizations setup which shows that I have a single Organizational Unit with a single account in it.
In this POC account, I have an IAM Role (“ExampleRole”) that I don’t want anybody to be able to delete (including the Root user), yet I still want people to be able to add/remove other IAM Roles as they see fit.
Step 1: – Enable SCP Policies within AWS Organizations
For those who have never looked at configuration Service Control Policies within their AWS Organization before, the first thing you need to do is enable “Service Control Policies” under the “Enable / Disable Policy Types” section within the AWS Organization management console. To do this,
1: Browse to https://console.aws.amazon.com/organizations/home#/browse
2: Select your Root Organization Unit from the list
3: On the Right-Hand Side, make sure that “Service Control Policies” have been enabled. If not, click the “Enable” Link as shown below
Step 2 – Create a new Service Control Policy
Now that Service Control Policies have been enabled across out AWS Organization, we are ready to create a new SCP to prevent users from deleting our “ExampleRole” role from our POC account.
1: Browse to https://console.aws.amazon.com/organizations/home#/policies
2: By default, we will already have a single Service control policy call “FullAWSAccess”. It’s advisable not to edit this policy, so we start by creating a new policy.
3: Now we can give our new SCP a policy name, a description and define the policy.
4: For the policy itself, we can go ahead and craft a policy much like we would an IAM policy. For our use case, we will block actions that would modify or delete our IAM Role. We can simply take the below code block and replace the existing statement in the policy window.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyAccessToASpecificRole",
"Effect": "Deny",
"Action": [
"iam:AttachRolePolicy",
"iam:DeleteRole",
"iam:DeleteRolePermissionsBoundary",
"iam:DeleteRolePolicy",
"iam:DetachRolePolicy",
"iam:PutRolePermissionsBoundary",
"iam:PutRolePolicy",
"iam:UpdateAssumeRolePolicy",
"iam:UpdateRole",
"iam:UpdateRoleDescription"
],
"Resource": "*"
}
]
}
5: And now comes the new addition to SCP’s. We will add a resource definition to our SCP to only block the specific Roles we are interested in. To do this, we can replace the “Resource” line with the below code. Note that the “Account” section has been defined as a wildcard. This will ensure that the policy is applicable to any account within our Organization Unit.
"Resource": [ "arn:aws:iam::*:role/ExampleRole" ]
6: Now that we have our SCP applied we can go ahead and Create our policy.
7: We should now see our new policy appear in our policy list as shown below. To apply this new Policy to a particular Organization Unit, we need to browse back to “Organize Accounts”
8: If we select our organization Unit from the list, we can then select “Service Control Policies” from the Right-Hand side and get presented with a list of available SCPs we can apply. All we need to do is click the “Attach” link against our new policy to apply it.
9: And that’s it, users should no longer be able to update/delete our “ExampleRole” role within our POC accounts.
To confirm that our new Service Control Policy is working correctly we can log into our POC account with a user that has “AdministratorAccess” and try to delete the “ExampleRole”. When we do this, we are presented with an error message stating we lack the required permissions to perform the operation.
Conclusion
And that’s how we can now use “Resources” to add fine-grained controls to our Service Control Policies to add greater control and flexibility to our Multi-Account environments.
So, where can you go from here? With the addition of “Resources”, “Conditions” and “NotAction” to SCPs administrators now have a lot more options when designing their security architecture. A couple of potential use cases might include:
- Prevent users from Making Certain Changes, with Exceptions for Admins
- Enforcing Encryption across an entire organization unit
- Preventing certain accounts from using specific resource types (such as EC2 instance sizes)
- Denying users from using certain AWS regions
You might notice that a number of these use cases are already possible by defining IAM policies within the individual accounts. Using SCPs instead, allows AWS Administrators to centrally control all of your controls in a single place, rather than relying on individual accounts to implement them. This will greatly simplify your Account Vending Machine process as well as the number of places that require regular auditing by your security team. If you have specific use cases you’d like us to showcase, please leave a comment below.