Feature | AWS Organization SCP FullAWSAccess import + SCPs review & refinement

[exequielrafaela]

What?

• Consider we have FullAWSAccess SCP attached to all OUs by defaults. Therefore all the Accounts allow everything by default. However ours default and standard custom SCPs restrict the services that are allowed in that OU. Since the permissions are the joint of both SCPs.

• Since it pre-exists we should (not strictly necessary) import in our state through code and have the option to leave it without effect (consider that when we add our SCPs with less permissions we're automatically restricting our OUs permissions)

• https://github.com/binbashar/le-tf-infra-aws/blob/master/root-org/organizations/policies_scp.tf

• https://github.com/binbashar/le-tf-infra-aws/blob/master/root-org/organizations/policy_scp_attachments.tf

Current Leverage Reference Architecture AWS Org structure

By default, an SCP named FullAWSAccess is attached to every organization root, OU, and account. This default SCP allows all actions and all services. So in a new organization, until you start creating or manipulating the SCPs, all of your existing IAM permissions continue to operate as they did. As soon as you apply a new or modified SCP to the organization root or an OU that contains an account, the permissions that your users have in that account become filtered by the SCP. Permissions that used to work might now be denied if they're not allowed by the SCP at every level of the hierarchy down to the specified account.

So in other words before there would be no need to uncheck it, as Services that are not allowed in default || standard SCPs are denied. What we might (optionally) have to do then is to reflect FullAWSAccess in the terraform code.

Ref Link

• https://medium.com/@largeavian/visual-explanation-of-scp-inheritance-for-aws-organizations-a7d31a6ff23d

Why?

• We attach the explicitly allow (whitelisting) SCP to the OUs which makes only the intersection between FullAWSAccess w/ default || standard SCPs to be allowed
• The idea of the default SCP is to have a minimum of permissions common to most of the OUs (this could go in the root to apply to all OUs).
• Then the standard SCP is the generic one that allows everything, this was done this way to make the AWS Organization bootstrapping process simpler but it could be re-evaluated if needed.
• The ref arch is a generic baseline it can not cover all cases, as it is now it is not in favor of security but it makes it easier for us to move forward
• After the AWS Organization structure and the Cloud Solutions Architecture is stable consider that a correct implementation of SCPs depends on each case and should be adjusted based on it.
• We could define 2 moments in typical customer implementations:
  1. the initial one, in which we need flexibility to move forward and we do not know all the customer requirements;
  2. and a more advanced one, in which we can limit (harden) and customize the SCPs better based on what the customer really uses in order not to neglect the security aspect.

Read More

• https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html#scp-effects-on-permissions
• https://aws.amazon.com/organizations/getting-started/best-practices/