Control your Organizations Permission using "Service Control Policy (SCP)"
Tags: aws, scp, organization, policy
Published: 2022-04-14 18:51:26

If you are having a hard time managing your organization's permission or you are concerned about the IAM User or Role permission. Then this is for you. SCP (Service Control Policy) will solve your all problem. Just use it & take a long sleep. 

> If you don't have the organization already then follow [this](https://dev.to/noyonict/how-to-create-manage-multiple-aws-accounts-with-aws-organizations-6jn) 

**Service Control Policy (_SCP_)**: `Service control policies (SCPs)` are a type of `organizational policy` that helps you to `control access` to your `all accounts` of the organization. SCPs guarantee you that all of your accounts will stay within your organization’s `access control guidelines` (except the root account or management account of the organization). 

SCPs are not granting permissions to the accounts of your organizations but those that define a `guardrail` or `set limits` on the `actions` that the account's administrator can delegate to the `IAM users` and `roles` in the affected accounts. 

> Note: SCPs will affect the `IAM Users` and `Roles` of the affected accounts, `including the root user`. They don't affect resource-based policies directly. They also don't affect users or roles from accounts outside the organization.


## Enabling your Organization's SCP

Go to the Organization's management account or root account. Then open the `AWS Organizations` Console. 
Then from the `Policies` tab open `Service control policies`.
Just click the `Enable service control policies` button to enable `SCP` for your organization.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4xb9quk2zbf4zxywy9g0.png)

> Note: SCPs are available only in an organization that has all features enabled.

You have successfully enable the SCP. By detault the `FullAWSAccess` policy will be attached with all of the OUs and Accounts. 


**SCP Policies**:
- The SCP policy follows the same format as an IAM policy

- The SCP policy attaches to an OU(Organizational Unit) or a member account.

- Every OU or account must have one SCP policy attached. Default `FullAWSAccess` policy attached.

- These restrictions even override the administrators of member accounts in the organization. This block remains in effect even if an administrator of a member account explicitly grants such permissions in an IAM policy.

- The SCPs policies don't affect resource-based policies directly, also don't affect users or roles from accounts outside the organization.


## Create SCP Policies and attach/detach to OU/account
You can create as many Policies as you need. Policy syntex will be as like IAM policy.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xcgyb6x2k0d0tkaibeg5.jpg)

You can attach or detach policies from the SCP policy list.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/c12cnx69tpd46vur4yz0.png)

Or 
You can attach or detach it from the OU or account view. If you click any OU or account then it will show you the policy option as well also display all of the SCP policies. Then you just need to attach or detach the policies.


## Strategies for using SCPs

**Blocklist or deny list**: All actions are allowed by default, and you specify what `services and actions` are `prohibited`. `Default configuration`.

**Whitelist or allow list**: All actions are prohibited by default, and you specify what `services and actions` are `allowed`.


## Example
Suppose your Organizations Diagram looks like this:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qv9130qbo4deuhl3kyyc.png)

Here we can see we have 
- 1 Management Account
- 2 OUs (Organizational Units)
- 3 AWS member accounts. where
       - Account-1 and Account-2 under Suspended OU
       - Account-3 under Production OU

**Blocklist or deny list approach**: This is the Default configuration of AWS Organization SCP. Suppose we are very concerned about our Production `CloudWatch`, `Config`, `GuardDuty` & `CloudTrail` services and we don't want to allow anyone can disable those services. Then Blocklist or deny list approach will be best fix for this use cases.

Create a policy named `denyLogServices` (whatever you want):

```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "cloudwatch:DeleteAlarms",
        "cloudwatch:DeleteDashboards",
        "cloudwatch:DisableAlarmActions",
        "cloudwatch:PutDashboard",
        "cloudwatch:PutMetricAlarm",
        "cloudwatch:SetAlarmState",
        "config:DeleteConfigRule",
        "config:DeleteConfigurationRecorder",
        "config:DeleteDeliveryChannel",
        "config:StopConfigurationRecorder",
        "guardduty:AcceptInvitation",
        "guardduty:ArchiveFindings",
        "guardduty:CreateDetector",
        "guardduty:CreateFilter",
        "guardduty:CreateIPSet",
        "guardduty:CreateMembers",
        "guardduty:CreatePublishingDestination",
        "guardduty:CreateSampleFindings",
        "guardduty:CreateThreatIntelSet",
        "guardduty:DeclineInvitations",
        "guardduty:DeleteDetector",
        "guardduty:DeleteFilter",
        "guardduty:DeleteInvitations",
        "guardduty:DeleteIPSet",
        "guardduty:DeleteMembers",
        "guardduty:DeletePublishingDestination",
        "guardduty:DeleteThreatIntelSet",
        "guardduty:DisassociateFromMasterAccount",
        "guardduty:DisassociateMembers",
        "guardduty:InviteMembers",
        "guardduty:StartMonitoringMembers",
        "guardduty:StopMonitoringMembers",
        "guardduty:TagResource",
        "guardduty:UnarchiveFindings",
        "guardduty:UntagResource",
        "guardduty:UpdateDetector",
        "guardduty:UpdateFilter",
        "guardduty:UpdateFindingsFeedback",
        "guardduty:UpdateIPSet",
        "guardduty:UpdatePublishingDestination",
        "guardduty:UpdateThreatIntelSet",
        "cloudtrail:Delete*",
        "cloudtrail:Update*",
      ],
      "Resource": "*"
    }
  ]
}
```

Then 
- We need to attach this SCP policy to `Production OU`. Then It will be applicable for all accounts under `Production OU`. Even though if we add any other account to `Production OU` this policy will be applied there as well.

- Then detach the default  'FullAWSAccess' SCP policy. Because in the `Blocklist` approach All actions are allowed by default.

> Note: If you attach this policy to the Root OU then it will be effected all of your OUs and accounts. Which is not our usecase.

**Effect**: This SCP policy prevents users or roles in any affected account from disabling `CloudWatch`, `Config`, `GuardDuty` & `CloudTrail` or altering its configuration, either directly as a command or through the console. It effectively enables read-only access to the `CloudWatch`, `Config`, `GuardDuty` & `CloudTrail` information and resources. Even the root user of the affected account can't do this.


**Whitelist or allow list approach**: Suppose we have some legacy product under `Suspended OU`. Where only ec2, DynamoDB, and Lambda services are being used. So we don't want to expose all services of those accounts except those.  For this use case, the `whitelist` approach will be best fit for this usecase.

Create a policy named `allowLegacyServices` (whatever you want):

```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowsAllActions",
            "Effect": "Allow",
            "Action": [
              "ec2:*",
              "dynamodb:*",
              "lambda:*"
            ],
            "Resource": "*"
        }
    ]
}
```

Then 
- Attach the policy to the `Suspended OU`. Then It will be applicable for all accounts and OUs under `Suspended OU`.

- Then detach the default SCP permission `FullAWSAccess`. Otherwise both of the permission will be applied. Which is not the usecase. In the `Withlist` approach all actions are prohibited by default.

> Note: You can attach SCP policy to member account as well. But it is always recommanded that attach SCP policy to OU lavel Then it will be applied to all accounts and OUs under that OU.

**Effect**: This SCP policy allows users or roles in any affected account only `ec2`, `dynamoDB` & `lambda` information and resources. Except those nobody (Even Root User) can have any other permission. Even though the user has attached the other permission in his user or roles, he will not be getting the other permission. The maximum limit a user or role can get is defined by the SCP role.

> For more example follow [this](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html)


## Limitation
However, unless you are certain that all of the accounts in your organization were created after `September 15, 2017`, we recommend that you don't rely on SCPs to try to restrict these operations.

## Summary
SCP is a great way to manage your Organizations Permission from a central place. You can set a limit by allowing or denying the permission of our organizational OU(Organizational Unit) or a member account. It will give you good confidence in your organizational infrastructure. Try to use this in your organization and take a deep sleep.


To learn more, read the [AWS Organization Service control policies (SCPs) documentation](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html).

Thanks for reading! Happy Cloud Computing!

Connect with me: [Linkedin](https://www.linkedin.com/in/noyonict/)