AWS-service control policies

SCP is a policy document. It is a JSON document which can be attached to the organization as a whole by attaching them to the root container or can be attached to the OUs and lastly to individual AWS accounts

There will be two OUs one for production and one for development and the member accounts will be put into their respective OUs.

SCP inherits down the organization tree if attached the org container then it affects entire organization. If attached to OUs it affects the member accounts in the OU Management account is special in that the SCP does not affect the management account I.e management account can’t be restricted using SCP attached to it directly or indirectly It is beneficial and limitation. Because of that management account should not be used to manage AWS resources

SCP are account permission boundaries

They limit what AWS acct can do.(including acct root user)

Account Root user can’t be controlled but using SCP what the acct can be done can be restricted and what the identities of account can do.

But if the account could be restricted then in effect, the account root user is also restricted. (indirectly)

For ex. An SCP could be used to restrict the usage of an acct outside a region, to restrict the size of the EC2 instance to be used within the acct.

They DON'T grant any permissions

They just act as a boundary of what is allowed and not allowed

Allow List vs Deny List

There are two ways of applying service control policies

Allow List - Block by default and allow the ones in the allow list

Deny List - Allow all services and block the ones in the deny list

Deny list is default

When SCPs are enabled on the AWS org. AWS apply a default policy which is called full AWS access, applied to all the organization and all OUs.

In the default implementation, SCP have no effect since nothing is restricted but there is an implicit deny like IAM policies, when an SCP is applied

So the same priority rules applied: Explicit Deny Explicit allow Implicit Deny

Any service explicitly allowed by scp can be granted access to identities within that account, unless there’s an explicit deny within an SCP then a service can’t be granted

Explicit deny always wins

And in the absence of either and also an explicit allow SCP policy, there will be an implicit deny

Allow list implementation is a two part architecture.

First part, remove AWS full access policy. So only the default implicit deny is present. Add any services that you want to allow into a policy

So irrespective of the identity permissions the identities in the account are provided, they are allowed only to access the services in the allow list. This is far more secure as we need to specify which services need to explicitly allowed.

But the admin overhead is more as services needed to be added to the allow list

How SCPs impact permissions in an AWS acct.

Only permissions which are allowed within identity policies in the account and are allowed by a service control policy are actually active.

Effective permissions for identities within an acct are the overlap between any identity policies and applicable SCPs

Service Control Policies

Comments

AWS Solution Architect - Associate Series

Cloud Watch Logs

More from this blog

The First Way: The Principles of Flow: Part-1

Types of Object Encryption in AWS S3

AWS Key Management Service - An Introduction

AWS S3 Performance Optimization

S3 Object Versioning & MFA Delete

Allow List vs Deny List

How SCPs impact permissions in an AWS acct.

Command Palette

Comments

AWS Solution Architect - Associate Series

Cloud Watch Logs

More from this blog

Allow List vs Deny List

How SCPs impact permissions in an AWS acct.