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 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 UsersandRolesof 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.
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
FullAWSAccesspolicy 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 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 underProduction OU. Even though if we add any other account toProduction OUthis policy will be applied there as well.Then detach the default 'FullAWSAccess' SCP policy. Because in the
Blocklistapproach 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 underSuspended OU.Then detach the default SCP permission
FullAWSAccess. Otherwise both of the permission will be applied. Which is not the usecase. In theWithlistapproach 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
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.
Thanks for reading! Happy Cloud Computing!
Connect with me: Linkedin
Top comments (2)
Thank you your page is quite useful for me. I really feel very pleased when identified your page . Kamakhya devi vashikaran mantra
Thanks for sharing