More about AWS Service Control Policies (SCP)
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.
OBS: Organization is a global service that is physically hosted in the US East (N. Virginia) Region (us-east-1). Therefore, you must use us-east-1 to access Organizations' quotas when using the Service Quotas console, the AWS CLI, or an AWS SDK.
AWS Service Control Policies(SCP) are Deny and Allow policies, it works just like any other JSON policy in AWS, but Service Control Policies(SCP) are set it up at the Organization level and are inherited by all other Organization Units, Sub-Organization Units, and Account bellow. They are enabled at your management account (Master Account) of your AWS Organization.
By default, when you activate the Service Control Policies, it comes with the policy “FullAWSAccess” at the root of your Organization, every OU and account.
Pay attention to this: “Allows” are not inherited, so in case you have an SCP with this kind of specification it will need to set it up at every level between the member account and the root of your Organization(see the documentation here)
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}OBS: If your delete or inactivate this, you won’t be able to do any kind of action, so by any means, Don’t touch this one!
SCPs alone are not sufficient to grant permissions to the accounts in your organization. No permissions are granted by an SCP. An SCP defines a guardrail or sets limits, on the actions that the account’s administrator can delegate to the IAM users and roles in the affected accounts. The administrator must still attach identity-based or resource-based policies to IAM users or roles, or to the resources in your accounts to actually grant permissions. The effective permissions are the logical intersection between what is allowed by the SCP and what is allowed by the IAM and resource-based policies.
Here is a Sketch of the Policy Evaluation:
Service Control Policies — Quotas
OBS: These numbers apply to only those policies that are directly attached to an OU or an account. Policies that affect an OU or account by inheritance do not count against these limits.
Since AWS Service Control Policies(SCP) are policies, there is also a quota for the policy size of 5120 bytes (not characters). Remember extra white spaces (such as spaces and line breaks) are also counted as characters, pay attention to this. If you save the policy by using the AWS Management Console, extra white space between JSON elements and outside quotation marks is removed and not counted. If you save the policy using an SDK operation or the AWS CLI, then the policy is saved exactly as you provided and no automatic removal of characters occurs.
Service Control Policies — Syntax
The SCP follows a similar syntax used by AWS Identity and Access Management (IAM) permission policies and resource-based policies.
An SCP is a plaintext file that is structured according to the rules of JSON.
Element Summary:
Use and abuse of the “Condition” filter. I have worked with SCPs at a company level and can say by experience that I used to use them a lot. We had conditions with strings in the name like “LandingZone” for the Organization’s Lading Zone resources; “custodian-” for Cloud Custodian Resources so users couldn’t update custodian lambdas in their project account(to bypass the Organization security standards/baselines); Roles name with wildcard(*) in the account id so only the automation roles can do the action; Region restrictions; and many others.
Testing
I strongly recommend that you test all of your SCPs in all possible (and impossible) scenarios. SCPs are at Organization Level, you can develop for one scenario and end up messing up something in another department or even exceptions cases like different types of account structure, projects, and so on.
Usually, when talking about big companies, there is always a Develop Landing zone or Develop Control tower. To test your SCPs you can create a specific Organization Unit for SCP testing or test account (Preferable an OU for this) so you and your team can rightfully test everything. If you want to test it out in your own personal account, you can create the SCO by the AWS Console and attach it to a specific OU, do as you prefer.
Deploying
To deploy the SCPs in an Organization is a little tricky, because there is always a workflow that needs to be followed, something like this:
The blue ones are actions from the Team that is responsible for the SCPs. This is just an example of workflow, as you can see the process can be very complex depending on the Organization's standards for it.
In an organization, this can be deployed by the Landing Zone Pipeline(in my scenario the pipeline deployed the SCP, Landing Zone resources, and several other things, so this had to have approval from the Foundation team and deployed on a Friday after the business hours); or Deployed using a pipeline specific for Service Control Policies in a Control Tower environment; Can have many cases in each company.
Closure
Service control policies (SCPs) offer high-level management and configuration and it is a great feature that companies should take advantage of more times.
It can be used in place of some Guardrails, decrease the deployment time of them and compute consumption within the Organization.
Of course with it comes more work when thinking about how and where to test this thing, adjustment of the capabilities of your Team, process definition, and approval flow for the deployment.
Feel free to test in your own personal account and comment what your think about it.
And take a look at the AWS documentation here
