I am not ashamed to admit I don’t know everything in AWS to the nth degree and that everyday is a learning day.
Recently helping out a customer I stumbled on something I had not known before now so I figured I’d blog about it. If it seemed obvious to you then well I guess I failed 😉
In short the goal was to add an SCP policy to restrict all accounts from being able to create an EC2 instance being made without a certain tag. Pretty simple eh and relatively well documented already in the SCP Policy Examples.
As part of the process my customer decided they needed to test this out in a new set of accounts.
They due fully setup 3 new accounts with a new org. During their tests it was noted the SCP examples from AWS were not working. So I did the usual checks:
- Is SCP Enabled?
- Double check the policy itself
- Check the SCP Policy attachments to OUs / Root / Accounts
Everything looked fine!
So I then jumped on my own set of accounts and gave it an run though. Lo and behold it worked for me right up to EC2 instance creation / deny.
I turns out that there were differences between the way we were conducting tests between the two environments.
Where my customer was applying the SCP to all accounts they only tested EC2 creation in their master account.
I was testing on a member account.
This led me to believe that SCPs don’t apply to master which I felt was odd because the docs say it applies to all accounts; or so it seemed:
Under Policy Types section: ” Service control policies (SCPs) offer central control over the maximum available permissions for all accounts your organization. “
Testing proved this statement NOT to be the case and that our suspicions around SCP’s not applying to master were in fact true.
Hunting around on the internet found a few references and this line buried in the docs under the “Remove the Master Account and Delete the Organization” section:
“The master account of an organization is never affected by service control policies (SCPs)”
Ok! So that so solves that mystery. #AWSFixYourDocsPlease
During our travels we also investigated the new AWS Organization tag policy service introduced into the orgs.
There is an enforce option in there which on the surface sounds like it can stop things happening if tags are not compliant.. We did some testing and reading. The short story is. it is for tags only.
It is not the same as SCP policies and this is mentioned late into the blog as found here: https://aws.amazon.com/blogs/aws/new-use-tag-policies-to-manage-tags-across-multiple-aws-accounts/ where at the end there is a juicy bullet point that states:
“Tags for New Resources – I can use Org-level Service Control Policies or IAM policies to prevent the creation of new resources that are not tagged in accord with my organization’s internal standards (see Require a Tag Upon Resource Creation for an example policy).”
So key take aways:
- Service Control Policies don’t apply to master. You need separate IAM policies to do the same job of locking down EC2.
- Tag policies are literally for tags only and therefore their enforcement is related to what people can and cannot add as tags to resources.
Hope this helps someone else.