Service Control Policies

I will summarize my notes on service control policies in this short post. Service control policies are used in AWS organizations to apply limits to member accounts. If we think of an AWS organization as a tree structure, we have the organization at the top level. We can have accounts or organizational units that are direct descendants of the organization. The organizational units may have other organizational units under them or individual accounts.

Service Control Policy (SCP) limits can be applied to individual accounts, organizational units, and the entire organization. The policies flow downward from the applied point. This flow means that if a policy restricting all S3 access is applied at the organization level, no member account can use S3. But, if that same policy is applied at an OU level, only the accounts under that OU are prevented from using S3.

One special note about SCP limits is that there is an exception. The management account can be placed anywhere in the organization’s hierarchy. The management account, however, is not subject to any SCP limitations, no matter where it falls in the hierarchy.

There are two approaches to writing service control policies. The default is that all services are allowed in member accounts and that SCPs restrict services. This default is accomplished by a default policy that AWS adds to all organizations called FullAWSAccess:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*" 
        }
    ]
}

With this policy in place, adding specific deny policies will restrict them one by one - but anything not explicitly prohibited will be allowed in member accounts.

If this FullAWSAccess policy is removed, then the default policy will restrict all AWS resources in member accounts. If you want the member account to have access to any service, you will need to add an SCP with an explicit allow policy. For instance, the policy below enables an account to grant access to all s3 actions.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": "*"
        }
    ]
}

Another important point about service control policies is that they don’t grant any privileges. Instead, they serve as a permissions boundary for an account. For example, to be allowed access to a resource in a member account, a principal must be given access through specific IAM policies. This setup effectively means that service control policies work together with policies on account principals to grant the union of the two sets of permissions. For instance, if account policies allow access to all EC2 actions but the service control policy only provides access to a single region of EC2, then the policies that grant access in the account effectively only grant those permissions to the region the SCP permits.