AWS - IdenAccessManage - SCPs (Service Control Policies)

Posted Jul 18, 2020

By Grace L

29 min read

Service Control Policies (SCPs)

Service Control Policies (SCPs)

basic

one type of policy
use to manage organization
- Attaching an SCP to an AWS Organizations entity (root, OU, or account)
- defines a guardrail for what actions the principals can perform.
enables permission controls
- can limit account usage to organizational units or linked accounts.
- offer central control over the maximum available permissions for all accounts in organization
- ensure accounts stay in organization’s access control guidelines.
available only in an organization that has all features enabled
- SCPs are not automatically enabled;
- including consolidated billing
  - SCPs aren’t available if organization has enabled only the consolidated billing feature
restrict the root user of an Organization Unit account
- SCP is a way to restrict a root user on an account.
- defines a safeguard for the actions that accounts in the organization root or OU can do.
- Attaching an SCP to the organization root/unit (OU)
  - Log in to the master account and create the SCP
  - Select the Organizational Unit
  - Enable the SCP
    for the Organizational Unit
  - Attach the SCP to the member account within the Organizational Unit
not a substitute for well-managed each account
- still need attach IAM policies to users/roles in organization’s accounts
- to actually grant permissions to them.
similar to IAM permissions policies
- almost the same syntax. JSON
- but, SCP policies never grants permissions.
  - it the maximum permissions
    for an organization or OU.
No permissions are granted by an SCP
- it defines a guardrail, or sets limits, on the actions that the account’s administrator can delegate to the IAM users/roles in the affected accounts.
  - The administrator must still attach identity/resource-based policies to IAM users/roles, or to the resources in accounts to actually grant permissions.
- The effective permissions
  - the logical intersection between what is allowed by the SCP and what is allowed by the IAM/Resource-based policies
- Important
  - SCPs don’t affect users or roles in the management account.
  - affect only the member accounts in the organization.
by default FullAWSAccess
- a service control policy
- allows users to access services/resources on an attached account.
- allows access to all AWS services within an attached member account

Testing effects of SCPs

recommends don’t attach SCPs to the root of the organization without thoroughly testing the impact that the policy has on accounts.

Instead, create an OU that you can move the accounts into one at a time, or at least in small numbers, to ensure that you don’t inadvertently lock users out of key services.

to determine whether a service is used by an account

Maximum size of SCPs

All characters in the SCP count against its maximum size.

if the policy size approaches the maximum size, delete any white space, such as space characters and line breaks that are outside quotation marks.

Use the visual editor to build the SCP. It automatically removes extra white space.

Inheritance of SCPs in the OU hierarchy

[Detailed explanation]

Effects on permissions

similar to AWS IAM permission policies and use almost the same syntax.
However, an SCP never grants permissions.
Instead, SCPs are JSON policies that specify the maximum permissions for the affected accounts.
SCPs affect only IAM users/roles managed by accounts that are part of the organization
- don’t affect resource-based policies directly.
- also don’t affect users or roles from accounts outside the organization.
- For example
- an Amazon S3 bucket that’s owned by account A in an organization.
- The bucket policy (resource-based policy) grants access to users from account B outside the organization.
- Account A has an SCP attached that doesn’t apply to those outside users in account B.
- The SCP applies only to users that are managed by account A in the organization.
SCP restricts permissions for IAM users/roles in member accounts, including the member account's root user
- Any account has only those permissions permitted by every parent above it.
- If a permission is blocked at any level above the account
  - either implicitly
    - not being included in an Allow policy statement
  - or explicitly
    - being included in a Deny policy statement
- a user/role in the affected account can’t use that permission
- even if the account administrator attaches the AdministratorAccess IAM policy with */* permissions to the user.
SCPs affect only member accounts in the organization
- They have no effect on users or roles in the management account.
Users/roles must still be granted permissions by IAM permission policies
- A user without any IAM permission policies has no access, even if the applicable SCPs allow all services and all actions.
- If a user/role has an IAM permission policy grants access to an action that is also allowed by the applicable SCPs
  - the user/role can perform that action.
- If a user/role has an IAM permission policy grants access to an action that is not allowed or explicitly denied by the applicable SCPs
  - the user/role can’t perform that action.
SCPs affect all users/roles in attached accounts, including the root user
- The only exceptions are
- some Tasks and entities not restricted by SCPs
  - Any action performed by the management account
  - Any action performed using permissions that are attached to a service-linked role
  - Register for the Enterprise support plan as the root user
  - Change the AWS support level as the root user
  - Manage Amazon CloudFront keys as the root user
  - Provide trusted signer functionality for CloudFront private content
  - Configure reverse DNS for an Amazon Lightsail email server as the root user
  - Tasks on some AWS-related services:
    - Alexa Top Sites
    - Alexa Web Information Service
    - Amazon Mechanical Turk
    - Amazon Product Marketing API
- Exceptions for only member accounts created before September 15, 2017
  - can’t use SCPs to prevent the root user in those member accounts from performing the following tasks:
  - Enable or disable multi-factor authentication on the root user
  - Create, update, or delete x.509 keys for the root user
  - Change the root user’s password
  - Create, update, or delete root access keys
- For all accounts created after September 15, 2017, the exceptions don’t apply and you *can- use SCPs to prevent the root user in those member accounts from performing the following tasks.
- However, unless you are certain that all of the accounts in the organization were created after September 15, 2017, recommend that don’t rely on SCPs to try to restrict these operations
SCPs do not affect any service-linked role
- Service-linked roles enable other AWS services to integrate with AWS Organizations
- can’t be restricted by SCPs.
disable the SCP policy type in a root
- all SCPs are automatically detached from all AWS Organizations entities in that root
  - AWS Organizations entities: organizational units, organizations, and accounts.
re-enable SCPs in a root
- that root reverts to only the default FullAWSAccess policy automatically attached to all entities in the root.
- Any attachments of SCPs to AWS Organizations entities from before SCPs were disabled are lost and aren’t automatically recoverable, although you can manually reattach them.
If both a permissions boundary (an advanced IAM feature) and an SCP are present
- then the boundary, the SCP, and the identity-based policy must all allow the action.

Using access data to improve SCPs

When signed in with management account credentials

IAM console > AWS Organizations section, view service last accessed data for an AWS Organizations entity or policy
or use the AWS CLI or AWS API in IAM to retrieve service last accessed data.

service last accessed data

includes information about which allowed services that the IAM users/roles in an AWS Organizations account last attempted to access and when.
use this information to identify unused permissions so that you can refine the SCPs to better adhere to the principle of least privilege

example

might have a deny list SCP that prohibits access to three AWS services.
All services that aren’t listed in the SCP’s Deny statement are allowed.
The service last accessed data in IAM tells you which AWS services are allowed by the SCP but are never used.
update the SCP to deny access to services that don’t need.

example:

create, update, and delete

When you sign in to the organization’s management account, you can create and update service control policies (SCPs)

building statements that deny or allow access to services and actions

The default configuration for working with SCPs is to use a “block list” strategy

where all actions are implicitly allowed except for those actions you want to block by creating statements that deny access.
With deny statements, you can specify resources and conditions for the statement and use the NotAction element.

use service last accessed data in IAM as a data point for updating the SCPs to restrict access to only the AWS services that you need.

Creating an SCP

Minimum permissions
- To create SCPs, need permission to run the following action:
- organizations:CreatePolicy
AWS CLI
- aws organizations create-policy
- Example
- assumes have a file named Deny-IAM.json with the JSON policy text in it.
- It uses that file to create a new service control policy.

  
$ aws organizations create-policy \
  --content file://Deny-IAM.json \
  --description "Deny all IAM actions" \
  --name DenyIAMSCP \
  --type SERVICECONTROLPOLICY
# {
#   "Policy": {
#       "PolicySummary": {
#           "Id": "p-i9j8k7l6m5",
#           "Arn": "arn:aws:organizations::123456789012:policy/o-aa111bb222/servicecontrolpolicy/p-i9j8k7l6m5",
#           "Name": "DenyIAMSCP",
#           "Description": "Deny all IAM actions",
#           "Type": "SERVICECONTROLPOLICY",
#           "AwsManaged": false
#       },
#       "Content": "{"Version":"2012-10-17","Statement":[{"Sid":"Statement1","Effect":"Deny","Action":["iam:*"],"Resource":["*"]}]}"
#   }
# }

AWS SDKs:
- CreatePolicy

Updating an SCP

Minimum permissions

To update an SCP, you need permission to run the following actions:
- organizations:UpdatePolicy
  - with a Resource element in the same policy statement that includes the ARN of the specified policy (or \*)
- organizations:DescribePolicy
  - with a Resource element in the same policy statement that includes the ARN of the specified policy (or \*)
AWS CLI:
- aws organizations update-policy
- Example

  
# renames a policy.
$ aws organizations update-policy \
  --policy-id p-i9j8k7l6m5 \
  --name "MyRenamedPolicy"
# {
#   "Policy": {
#       "PolicySummary": {
#           "Id": "p-i9j8k7l6m5",
#           "Arn": "arn:aws:organizations::123456789012:policy/o-aa111bb222/servicecontrolpolicy/p-i9j8k7l6m5",
#           "Name": "MyRenamedPolicy",
#           "Description": "Blocks all IAM actions",
#           "Type": "SERVICECONTROLPOLICY",
#           "AwsManaged": false
#       },
#       "Content": "{"Version":"2012-10-17","Statement":[{"Sid":"Statement1","Effect":"Den"Action":["iam:*"],"Resource":["*"]}]}"
#   }
# }


# adds or changes the description for a service control policy.
$ aws organizations update-policy \
  --policy-id p-i9j8k7l6m5 \
  --description "My new policy description"
  # {
  #       "Policy": {
  #           "PolicySummary": {
  #               "Id": "p-i9j8k7l6m5",
  #               "Arn": "arn:aws:organizations::123456789012:policy/o-aa111bb222/servicecontrolpolicy/p-i9j8k7l6m5",
  #               "Name": "MyRenamedPolicy",
  #               "Description": "My new policy description",
  #               "Type": "SERVICECONTROLPOLICY",
  #               "AwsManaged": false
  #           },
  #           "Content": "{"Version":"2012-10-17","Statement":[{"Sid":"Statement1","Effect":"Deny","Action":["iam:*"],"Resource":["*"]}]}"
  #       }
  # }


# changes the policy document of the SCP by specifying a file that contains the new JSON policy text.
$ aws organizations update-policy \
  --policy-id p-zlfw1r64
  --content file://MyNewPolicyText.json
  # {
  #       "Policy": {
  #           "PolicySummary": {
  #               "Id": "p-i9j8k7l6m5",
  #               "Arn": "arn:aws:organizations::123456789012:policy/o-aa111bb222/servicecontrolpolicy/p-i9j8k7l6m5",
  #               "Name": "MyRenamedPolicy",
  #               "Description": "My new policy description",
  #               "Type": "SERVICECONTROLPOLICY",
  #               "AwsManaged": false
  #           },
  #           "Content": "{"Version":"2012-10-17","Statement":[{"Sid":"AModifiedPolicy","Effect":"Deny","Action":["iam:*"],"Resource":["*"]}]}"
  #       }
  # }

AWS SDKs:
- UpdatePolicy

Editing tags attached to an SCP

add or remove the tags attached to an SCP. For more information about tagging

Minimum permissions
- To edit the tags attached to an SCP in the AWS organization, you must have the following permissions:
  - organizations:DescribeOrganization – required only when using the Organizations console
  - organizations:DescribePolicy – required only when using the Organizations console
  - organizations:TagResource
  - organizations:UntagResource
AWS CLI:
- aws organizations tag-resource
- aws organizations untag-resource
AWS SDKs:
- TagResource
- UntagResource

Deleting an SCP

Before you can delete a policy, you must first detach it from all attached entities.
can’t delete any AWS managed SCP such as the SCP named FullAWSAccess.
Minimum permissions
- To delete an SCP, you need permission to run the following action:
- organizations:DeletePolicy
AWS CLI:
- aws organizations delete-policy

  
$ aws organizations delete-policy \
  --policy-id p-i9j8k7l6m5
  # This command produces no output when successful.

AWS SDKs:
- DeletePolicy

Attach and detach

Attach

Minimum permissions

To attach an SCP to a root, OU, or account, you need permission to run the following action:
organizations:AttachPolicy
- with a Resource element in the same policy statement that
  - includes
  - * or the Amazon Resource Name (ARN) of the specified policy
  - and the ARN of the root, OU, or account that you want to attach the policy to
AWS CLI:

  
$ aws organizations attach-policy \
    --policy-id p-i9j8k7l6m5 \
    --target-id ou-a1b2-f6g7h222
This command produces no output when successful.

AWS SDKs: AttachPolicy

Detaching an SCP from the organization root, OUs, or accounts

You can’t detach the last SCP from a root, an OU, or an account. There must be at least one SCP attached to every root, OU, and account at all times.

Minimum permissions

To detach an SCP from the root, OU, or account, you need permission to run the following action:
organizations:DetachPolicy
AWS CLI:

  
$ aws organizations detach-policy \
    --policy-id p-i9j8k7l6m5 \
    --target-id ou-a1b2-f6g7h222

AWS SDKs: DetachPolicy

Strategies for using SCPs

configure the service control policies (SCPs) as either of the following:

A deny list strategy
- actions are allowed by default,
- and you specify what services and actions are prohibited
- makes use of the FullAWSAccess SCP attached by default to every OU and account.
- This SCP
  - overrides the default implicit deny
  - explicitly allows all permissions from the root to every account
  - unless explicitly deny a permission with an additional SCP created and attached to the appropriate OU or account.
- This strategy works because an explicit deny in a policy always overrides allow
- No account below the level of the OU with the deny policy can use the denied API
- and there is no way to add the permission back lower in the hierarchy.
An allow list strategy
- actions are prohibited by default
- and you specify what services and actions are allowed
- remove the FullAWSAccess SCP ttached by default to every OU and account.
- no APIs are permitted anywhere unless you explicitly allow them.
- To allow a service API to operate in an AWS account, you must create your own SCPs and attach them to the account and every OU above it, up to and including the root.
- Every SCP in the hierarchy, starting at the root, must explicitly allow the APIs to be usable in the OUs and accounts below it.
- This strategy works because an explicit allow in an SCP overrides an implicit 暗示的 deny

SCPs `FullAWSAccess`

AWS Organizations attaches an AWS managed SCP named FullAWSAccess to every root and OU when it’s created.

This policy allows all services and actions.
attach or detach from the entities in your organization as needed.
Because the policy is an AWS managed SCP, you can’t modify or delete it.

The policy looks like the following.

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

Using SCPs as a deny list

The default configuration of AWS Organizations supports using SCPs as deny lists.

Using a deny list strategy
account administrators can delegate all services and actions until you create and attach an SCP that denies a specific service or set of actions.
Deny statements require less maintenance,
- no need to update them when AWS adds new services.
Deny statements usually use less space
- easier to stay within the maximum size for SCPs.
In a statement where the Effect element has a value of Deny, you can also restrict access to specific resources, or define conditions for when SCPs are in effect.

Such a policy might look like the following example

  

// 1.
// This SCP still allows all other services and their actions.
// prevents users in the affected accounts from performing any actions for the Amazon DynamoDB service.
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowsAllActions",
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        },
        {
            "Sid": "DenyDynamoDB",
            "Effect": "Deny",
            "Action": "dynamodb:*",
            "Resource": "*"
        }
    ]
}


// 2. leaving the FullAWSAccess policy in place
// and then attaching a second policy that has only the Deny statement in it
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "dynamodb:*",
            "Resource": "*"
        }
    ]
}

Using SCPs as an allow list

must replace the AWS managed FullAWSAccess SCP with an SCP that explicitly permits only those services and actions that you want to allow.
By removing the default FullAWSAccess SCP, all actions for all services are now implicitly denied.
Your custom SCP then overrides the implicit Deny with an explicit Allow for only those actions that you want to permit.
For a permission to be enabled for a specified account, every SCP from the root through each OU in the direct path to the account, and even attached to the account itself, must allow that permission.

An Allow statement in an SCP

can’t have a Resource element with anything except a “*”.
can’t have a Condition element at all.

An allow list policy might look like the following example

  
// enables account users to perform operations for Amazon Elastic Compute Cloud (Amazon EC2) and Amazon CloudWatch, but no other service.
//  All SCPs in parent OUs and the root also must explicitly allow these permissions.
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:*",
                "cloudwatch:*"
            ],
            "Resource": "*"
        }
    ]
}

SCP syntax

Elements summary

Element	Purpose	Supported effects
Version	Specifies the language syntax rules to use for processing the policy.	`Allow`, `Deny`
Statement	Serves as the container for policy elements. You can have multiple statements in SCPs.	`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.	`Allow`, `Deny`
NotAction	Specifies AWS service and actions that are exempt from the SCP. Used instead of the `Action` element.	`Deny`
Resource	Specifies the AWS resources that the SCP applies to.	`Deny`
Condition	Specifies conditions for when the statement is in effect.	`Deny`

`*`

It is case sensitivity in SCP

the Action and NotAction are case sensitive and must be typed as shown in each service’s documentation.

can use an asterisk (*) as a wildcard to match multiple actions that share part of a name,

however, the wildcard characters (*) and (?) in an Action or NotAction element can be used only by itself or at the end of the string.
It can’t appear at the beginning or middle of the string.
"servicename:action*" is valid,
but "servicename:*action" and "servicename:some*action" are both invalid in SCPs.

`Version` element

Every SCP must include a Version element with the value "2012-10-17".
This is the same version value as the most recent version of IAM permission policies.

"Version": "2012-10-17",

`Statement` element

An SCP consists of one or more Statement elements.
can have only one Statement keyword in a policy,
- but the value can be a JSON array of statements (surrounded by [ ] characters).
- single statement consists of single Effect, Action, and Resource elements.

  
"Statement": {
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

// two statements as an array list inside one `Statement` element.

"Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        },
        {
            "Effect": "Deny",
            "Action": "ec2:*",
            "Resource": "*"
        }

Statement ID (`Sid`) element

optional identifier that you provide for the policy statement.
You can assign a Sid value to each statement in a statement array.
The following example SCP shows a sample Sid statement.

  
{
    "Statement": {
        "Sid": "AllowsAllActions",
        "Effect": "Allow",
        "Action": "*",
        "Resource": "*"
    }
}

`Effect` element

Each statement must contain one Effect element.

The value can be either Allow or Deny.
It affects any actions listed in the same statement.

Even though this statement uses the same Allow value keyword as an IAM permission policy, in an SCP it doesn’t actually grant a user permission to do anything.

Instead, SCPs act as filters that specify the maximum permissions for the accounts in an organization, organizational unit (OU), or account.
even if a user in the account had the AdministratorAccess managed policy attached, this SCP limits all users in affected accounts to only Amazon S3 actions.

`"Effect": "Allow"`

permits account users to perform actions for the Amazon S3 service.

  
// the statement allows the Amazon S3 permissions for any attached accounts:
{
    "Statement": {
        "Effect": "Allow",
        "Action": "s3:*",
        "Resource": "*"
    }
}

`"Effect": "Deny"`

restrict access to specific resources or define conditions for when SCPs are in effect.

  
{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Deny",
        "Action": "ec2:RunInstances",
        "Resource": "arn:aws:ec2:*:*:instance/*",
        "Condition": {
            "StringNotEquals": {
                "ec2:InstanceType": "t2.micro"
            }
        }
    }
}
// prevent affected accounts from launching Amazon EC2 instances if the Amazon EC2 instance isn't set to `t2.micro`.
// Even if an IAM policy that allows this action is attached to the account, the guardrail created by the SCP prevents it.

`Action` and `NotAction` elements

Each statement must contain one of the following:

In allow and deny statements, an Action element.
In deny statements only, an Action or NotAction element.

The value for the Action or NotAction element is

a list (a JSON array) of strings
- identify AWS services and actions that are allowed or denied by the statement.
- Each string consists of the abbreviation for the service (such as “s3”, “ec2”, “iam”, or “organizations”), in all lowercase,
- followed by a colon
- and then an action from that service.
The actions and notactions are case sensitive
- must be typed as shown in each service’s documentation.
- Generally, they are all typed with each word starting with an uppercase letter and the rest lowercase.
- For example: "s3:ListAllMyBuckets".
use an asterisk as a wildcard to match multiple actions that share part of a name.
- The value "s3:*" means all actions in the Amazon S3 service.
- The value "ec2:Describe*" matches only the EC2 actions that begin with “Describe”.
- In an SCP, the wildcard * character in an Action or NotAction element
  - can be used only by itself or at the end of the string.
  - It can’t appear at the beginning or middle of the string.
    - "servicename:action*" is valid,
    - "servicename:*action" and "servicename:some*action" are both invalid in SCPs.

list of all the services and the actions that they support in both AWS Organizations SCPs and IAM permission policies

Actions, Resources, and Condition Keys for AWS Services in the IAM User Guide.

`Action` element

an example of an allow list

useful when the default Allow * policies are not attached so that ermissions are implicitly denied.
If the default Allow * policy is still attached, the policy has no effect.

  
// permits account administrators to delegate describe, start, stop, and terminate permissions for EC2 instances in the account.
{
    "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": "*"
    }
}

an example of an deny list

deny access to services that you don’t want used in attached accounts.
It assumes that the default "Allow *" SCPs are still attached to all OUs and the root.

  
// prevents the account administrators in attached accounts from delegating any permissions for the IAM, Amazon EC2, and Amazon RDS services.
// Any action from other services can be delegated as long as there isn't another attached policy that denies them.
{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Deny",
        "Action": [ "iam:*", "ec2:*", "rds:*" ],
        "Resource": "*"
    }
}

Example of `NotAction` element ???

use a NotAction element to exclude AWS services from the effect of the policy.

  
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "LimitActionsInRegion",
      "Effect": "Deny",
      "NotAction": "iam:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": "us-west-1"
         }
       }
     }
   ]
}
// affected accounts are limited to taking actions in the specified AWS Region, except when using IAM actions.

`Resource` element

In statements Effect element has a value of Allow

you can specify only \* in the Resource element of an SCP ???
You can’t specify individual resource Amazon Resource Names (ARNs).

In statements Effect element has a value of Deny

you can specify individual ARNs

  
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAccessToAdminRole",
      "Effect": "Deny",
      "Action": [
        "iam:AttachRolePolicy",
        "iam:DeleteRole",
        "iam:DeleteRolePermissionsBoundary",
        "iam:DeleteRolePolicy",
        "iam:DetachRolePolicy",
        "iam:PutRolePermissionsBoundary",
        "iam:PutRolePolicy",
        "iam:UpdateAssumeRolePolicy",
        "iam:UpdateRole",
        "iam:UpdateRoleDescription"
      ],
      "Resource": [
        "arn:aws:iam::*:role/`role-to-deny`"
      ]
    }
  ]
}
// This SCP restricts IAM users and roles in affected accounts from making changes to a common administrative IAM role created in all accounts in your organization.

`Condition` element

You can specify a Condition element in deny statements in an SCP.

  
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyAllOutsideEU",
            "Effect": "Deny",
            "NotAction": [
                "cloudfront:*",
                "iam:*",
                "route53:*",
                "support:*"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "aws:RequestedRegion": ["eu-central-1","eu-west-1"]
                }
            }
        }
    ]
}
// This SCP denies access to any operations outside the `eu-central-1` and `eu-west-1` Regions
// except for actions in the listed services.

For more information, see IAM JSON Policy Elements: Condition in the IAM User Guide.

multiple condition

PolicyA: Deny CreateNotebookInstance if both value is “Enabled”

if both parameter are missing (null), API been denied
if one parameter is missing, API been denied
if both parameter existed and are “Enabled” (are not “Disabled”), API been denied
if both parameter existed and are “Disabled” (are not “Enabled”), API Pass.

  
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "sagemaker:CreateNotebookInstance",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "sagemaker:DirectInternetAccess": "Enabled"
        }
      }
    },
    {
      "Effect": "Deny",
      "Action": "sagemaker:CreateNotebookInstance",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "sagemaker:RootAccess": "Enabled"
        }
      }
    }
  ]
}

PolicyB: Deny CreateNotebookInstance and UpdateNotebookInstance if any of the values is not “Disabled”

if both parameter are null, 2 APIs been denied
if DirectInternetAccess is null and the other is Enabled, 2 APIs been denied
if DirectInternetAccess is null and the other is Disabled, only “CreateNotebookInstance” been denied
if RootAccess is null and the other is Enabled, 2 APIs been denied
if RootAccess is null and the other is Disabled, 2 APIs been denied
if both parameter existed and are Enabled (are not Disabled), 2 APIs been denied
if both parameter existed and are Disabled (are not Enabled), 2 APIs Pass.

  
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "sagemaker:CreateNotebookInstance",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "sagemaker:DirectInternetAccess": "Disabled"
        }
      }
    },
    {
      "Effect": "Deny",
      "Action": [
        "sagemaker:CreateNotebookInstance",
        "sagemaker:UpdateNotebookInstance"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "sagemaker:RootAccess": "Disabled"
        }
      }
    }
  ]
}

Duplicate String Operator is not allowed as per JSON syntax

PolicyC:

if both parameter are null, 2 APIs been denied (?)
if one parameter is null and the other is Enabled, 2 APIs been denied (?)
if one parameter is null and the other is Disabled, 2 APIs been denied (?)
if both parameter existed and are “Enabled” (are not “Disabled”), 2 APIs been denied
if both parameter existed and are “Disabled” (are not “Enabled”), 2 APIs Pass.

  
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "sagemaker:CreateNotebookInstance",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "sagemaker:DirectInternetAccess": "Disabled"
        },
        "StringNotEquals": {
          "sagemaker:RootAccess": "Disabled"
        }
      }
    }
  ]
}
// This policy is not valid since it has Duplicate “StringNotEquals” operator.
// After saving the SCP policy console automatically removed duplicate condition (“ForAnyValue:StringNotEquals": { "sagemaker:DirectInternetAccess": “Disabled”) from the SCP policy.


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "sagemaker:CreateNotebookInstance",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "sagemaker:DirectInternetAccess": "Disabled"
        },
        "StringEquals": {
          "sagemaker:RootAccess": "Disabled"
        }
      }
    }
  ]
}
// In the above policy, AND logic will be applied
// the API call will only be allowed when “DirectInternetAccess” is “Enabled” since it’s used with “StringNotEquals” operator and “RootAccess” is “Disabled” since it is used with “StringEquals” operator.

Result:
- DirectInternetAccess -> Enabled ----------------> Deny
- RootAccess -> Disabled

- DirectInternetAccess -> Enabled ———-—————> Allow
- RootAccess -> Enabled

- DirectInternetAccess -> Disabled --------------> Allow
- RootAccess -> Enabled

- DirectInternetAccess -> Disabled ----------------> Allow
- RootAccess -> Disabled

PolicyD: Good

if both parameter are null, 2 APIs been denied (?)
if one parameter is null and the other is Enabled, 2 APIs been denied (?)
if one parameter is null and the other is Disabled, 2 APIs been denied (?)
if both parameter existed and are “Enabled” (are not “Disabled”), 2 APIs been denied
if both parameter existed and are “Disabled” (are not “Enabled”), 2 APIs Pass.

  
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "sagemaker:CreateNotebookInstance",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "sagemaker:DirectInternetAccess": "Disabled",
          "sagemaker:RootAccess": "Disabled"
        }
      }
    }
  ]
}
// You need to select “Enabled” or “Disabled”
// if not, it will take default value for the keys which is “Enabled”.
// - if either parameter are `Disabled`, allow
// - if both parameter are `Enabled` (are not `Disabled`), 2 APIs been denied

PolicyE:

if both parameter are null, 2 APIs been denied (?)
if one parameter is null and the other is Enabled, 2 APIs been denied (?)
if one parameter is null and the other is Disabled, 2 APIs been denied (?)
if both parameter existed and are “Enabled” (are not “Disabled”), 2 APIs been denied
if both parameter existed and are “Disabled” (are not “Enabled”), 2 APIs Pass. ```json { “Version”: “2012-10-17”, “Statement”: [ { “Effect”: “Deny”, “Action”: [ “sagemaker:CreateNotebookInstance”, “sagemaker:UpdateNotebookInstance” ], “Resource”: “*”, “Condition”: { “StringNotEquals”: { “sagemaker:DirectInternetAccess”: “Disabled”, “sagemaker:RootAccess”: “Disabled” } } } ] }

// - if both parameter are Disabled allow // - if one parameter are Enabled, allow // - if both parameter are Enabled (not Disabled), 2 APIs been denied ```

Unsupported elements

The following elements aren’t supported in SCPs:

Principal
NotPrincipal
NotResource

01AWS, IdenAccessManage

This post is licensed under CC BY 4.0 by the author.

Service Control Policies (SCPs)

basic

Testing effects of SCPs

Maximum size of SCPs

Inheritance of SCPs in the OU hierarchy

Effects on permissions

Using access data to improve SCPs

create, update, and delete

Creating an SCP

Updating an SCP

Editing tags attached to an SCP

Deleting an SCP

Attach and detach

Attach

Detaching an SCP from the organization root, OUs, or accounts

Strategies for using SCPs

SCPs FullAWSAccess

Using SCPs as a deny list

Using SCPs as an allow list

SCP syntax

*

Version element

Statement element

Statement ID (Sid) element

Effect element

"Effect": "Allow"

"Effect": "Deny"

Action and NotAction elements

Action element

Example of NotAction element ???

Resource element

Condition element

multiple condition

Unsupported elements

Trending Tags

SCPs `FullAWSAccess`

`*`

`Version` element

`Statement` element

Statement ID (`Sid`) element

`Effect` element

`"Effect": "Allow"`

`"Effect": "Deny"`

`Action` and `NotAction` elements

`Action` element

Example of `NotAction` element ???

`Resource` element

`Condition` element