Preventive guardrails are a key component of cloud governance. (Cloud governance is the process of defining and creating policies to control costs, minimize security risks, and improve efficiency.) In AWS, preventive guardrails are SCPs (Service Control Policies). Eventually you may need a preventive guardrail in AWS that is not already available. In this case, writing an SCP is an option. Beware, SCPs do have logical limitations on what you can represent.
What is an SCP?
Service Control Policies are a type of AWS Organizations policy that is used to manage permissions for your resources. SCPs allow you to centrally control over the permissions for all accounts in your organization. Thus, SCPs help you to ensure that your accounts stay within your organization’s access control guidelines. You can only use SCPs if you have all features enabled on your Organization, not only the consolidated billing features.
A Service Control Policy does not grant any permissions. SCPs only limit the actions a user can take. Consequently, an administrator can still attach IAM policies to grant permissions to allow access. The effective permissions are the logical intersection between what is allowed by the SCP and what is allowed by the IAM policy. For more information on the interactions between SCPs, IAM, and resource policies, see the AWS documentation. Think of SCPs as a filter that specifies the maximum permissions allowed.
The Anatomy of an SCP
You create an SCP by building a statement that either denies or allows access to services and actions that you specify. The following example shows a single statement that consists of single Effect
, Action
, and Resource
elements.
"Statement": {
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
The following table shows the elements that compose an SCP. Some effects are only available for deny statements.
Element | Purpose | Supported effects |
---|---|---|
Version | Specifies the language syntax rules to use for processing the policy. The current value is "2012-10-17" . | Allow , Deny |
Statement | Serves as the container for policy elements. You can have multiple statements in SCPs, separated by a comma. | Allow , Deny |
Statement ID (Sid) | (Optional) Provides a friendly name for the statement. | Allow , Deny |
Effect | Defines whether the SCP statement allows or denies access to the IAM users and roles in an account. | Allow , Deny |
Action | Specifies AWS service and actions that the SCP allows or denies. Can be a single action or a list of actions. Valid values use IAM action syntax. | Allow , Deny |
NotAction | Specifies AWS service and actions that are exempt from the SCP. Used instead of the Action element. Valid values use IAM not action syntax. | Deny |
Resource | Specifies the AWS resources that the SCP applies to. | Deny |
Condition | Specifies conditions for when the statement is in effect. Valid values use IAM condition syntax. | Deny |
Examples
The following SCP allows the user to perform any action on Amazon S3.
{
"Statement": {
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*"
}
}
The following SCP limits the user from launching EC2 instances that are not t2.micro.
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"StringNotEquals": {
"ec2:InstanceType": "t2.micro"
}
}
}
}
Finally, the following SCP allows the user to describe, start, stop, and terminate EC2 instances.
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances", "ec2:DescribeImages", "ec2:DescribeKeyPairs",
"ec2:DescribeSecurityGroups", "ec2:DescribeAvailabilityZones", "ec2:RunInstances",
"ec2:TerminateInstances", "ec2:StopInstances", "ec2:StartInstances"
],
"Resource": "*"
}
}
Final Thoughts
As you can see, writing an SCP is not difficult. Having a knowledge of JSON syntax and IAM policy language is helpful, but not necessary. Determining if you want to write policies in an Allow or Deny fashion is the decision that requires the most strategy. If you have any questions or need help developing an Allow/Deny strategy, please reach out to us.