Following on the heels of my previous post, Five Functional Facts about AWS Identity and Access Management, I wanted to dive into a separate, yet related way of enforcing access policies in AWS: Service Control Policies (SCPs).

SCPs and IAM policies look very similar—both being JSON documents with the same sort of syntax—and it would be easy to mistake one for the other. However, they are used in different contexts and for different purposes. In this post, I'll explain the context where SCPs are used and why they are used (and even why you'd use SCPs and IAM policies together).

Read on, dear reader!

UPDATE: Thanks to my colleague Eric G for providing feedback that helped me improve the accuracy of the article!

1 - SCPs scope the permissions an AWS account has⌗

To properly describe SCPs, I need to introduce a new service: AWS Organizations. Organizations is a service that is used to bring multiple AWS accounts together under a common management structure. For example, if you wanted to enforce the use of encryption on S3 buckets across all the AWS accounts used within your company, you could do that via AWS Organizations. Additional benefits of Organizations include consolidated billing, integration with certain services such as AWS CloudTrail, and streamlined sharing of resources between accounts using AWS Resource Access Manager.

AWS Organizations group member accounts into a hierarchy of Organizational Units (OUs) underneath a pseudo root node.

Structure of AWS Organizations

Now back to SCPs. SCPs are the mechanism used to enforce management of accounts within the organization. For example:

  • Enforce encryption on S3 buckets
  • Deny altogether the use of a service or services
  • Prevent modification of how services are configured (such as AWS CloudTrail or AWS Config)
  • Deny specific API calls such as those needed to create and attach an Internet Gateway

If you consider that by default AWS accounts have access to all services on the platform, SCPs serve to reduce the scope of services and/or actions that an account can take against a service or services. Put another way: SCPs reduce the maximum permissions for an account.

2 - SCPs apply to all users and roles, even root!⌗

SCPs are created and managed within the context of an AWS Organization and can be attached to the following entities (at any level):

  • Organization root
  • Organizational Units (OU)
  • Accounts in the organization
Service Control Policy Attachment Points

This brings about some interesting behavior. First, an account within the org may be subject to multiple SCPs. It could have an SCP attached directly to it, it could be a member or sub-member of an OU that has an SCP attached, and there could be an SCP attached at the root of the org. The permissions an account is granted are those that each SCP permits. If a permission is blocked at any level, either implicitly (by not being included in an Allow statement) or explicitly (by being included in a Deny statement), a user or role in the affected account can't use that permission.

Secondly, since the SCP lives outside of the account that it's applied to, a user or role within the account that has administrative permissions cannot see or modify the SCP.

There's a small falsehood to that statement: the organization administration account is where AWS Organizations is configured and where the SCPs live. This account is subject to any SCPs applied to it just the same as member accounts. Best practice is to tightly control who has access to the org administration account for this very reason and not use it for anything other than administration of AWS Organizations.

Correction: The org management account is not subject to any SCPs. The documentation is subtle, but specific about this: "An SCP limits permissions for entities in member accounts".

Lastly, the permissions that an SCP allows in an account apply to every user and role in that account. Even the root user. Whether you're a limited-permission IAM user, a federated user, a user with the AdministratorAccess IAM policy, or even the root user in the account, the SCP(s) applied to the account are enforced on you.

Clarification: SCPs do apply to roles that are assigned to users and groups, but do not apply to service-linked roles which is a unique type of role that is linked directly to an AWS service.

3 - One SCP is always required⌗

The org root, every OU, and every account in the org must have at least one SCP attached. To satisfy this requirement when an org is first created, AWS Organizations contains an AWS-manged SCP called FullAWSAccess which is applied to every entity. This policy allows access to all AWS resources and all actions

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

A common pattern is to use the FullAWSAccess policy—which grants all access—and a user-defined policy which denies specific access to create an effective deny list policy. For example, attaching FullAWSAccess and the policy below to an account would allow the account to use all services and take all actions on those services, except for uploading objects to S3 without server-side encryption:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyIncorrectEncryptionHeader",
      "Effect": "Deny",
      "Action": "s3:PutObject",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption": "AES256"
        }
      }
    },
    {
      "Sid": "DenyUnEncryptedObjectUploads",
      "Effect": "Deny",
      "Action": "s3:PutObject",
      "Resource": "*",
      "Condition": {
        "Bool": {
          "s3:x-amz-server-side-encryption": false
        }
      }
    }
  ]
}

4 - Conditions are supported⌗

Just like I wrote about with IAM, conditions are supported in SCPs which allows for creating very dynamic and focused policies. The policy above about S3 encryption is a good example of using conditions to check for certain header values in the received API call.

See the References section below for a link to details on what conditions are available.

5 - SCPs do not affect principals from outside your org⌗

Hopefully my liberal application of italics in various places in this post drove the point home that SCPs affect all of the principals within an account, even root (more italics for you 😜). Now I need to ease up a bit and state that principals that are managed in accounts outside of your org are not subject to your SCPs.

As an example, let's say you created the SCP above to enforce S3 object encryption. You then created a bucket within one of your org member accounts and granted permission for an AWS account that belongs to a different company the rights to PUT objects into that bucket. Principals from that third party account would be able to upload objects without any encryption settings because the SCP doesn't apply to them. Only principals from within your AWS Organization are subject to your SCPs.

Best practice for a case like this would be to enforce all of your access controls and policies in an IAM policy that you apply to either the bucket or the role that you allow the third party to assume.

Summary⌗

Service Control Policies are used to enforce guard rails on AWS accounts used across your company or organization. SCPs don't replace IAM policies and can't be used to grant access to a principal; instead they serve to take away permissions from the account itself and limit what principals within the account are able to do. SCPs enable the enforcement of organization-wide policies in the areas of security, logging, service usage, and more, all from a central location.

References⌗

Disclaimer: The opinions and information expressed in this blog article are my own and not necessarily those of Amazon Web Services or Amazon, Inc.