Control your Organizations Permission using "Service Control Policy (SCP)"

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

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 organizations 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. It will not be affected any Service
policies.

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.

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.

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

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:

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 for this use cases.

Create a policy named denyLogServices:

{  "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.

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.

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 applicable.

Create a policy named allowLegacyServices:

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

Then we need to attach this SCP polity to Suspended OU. Then it will be applicable for all accounts under Suspended OU.

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.

Summary

SCP is a great way to manage your Organizations Permission. Try to use this in your organization and take a deep sleep.

To learn more, read the AWS Organization Service control policies (SCPs) documentation.

Thanks for reading! Happy Cloud Computing!

Connect with me: Linkedin