add account and sso to not_actions in DenyRegions and RestrictToSpecifiedRegions

[BFarand]

what

• Add account:* and sso:* as not_actions in the DenyRegions and RestrictToSpecifiedRegions SCPs.

why

• Like the other not_actions resources in the SCPs, these resources are provisioned in a specific AWS region that may not necessarily be the one explicitly allow/deny listed.
• sso:* being denied results in the entire AWS Identity Centre console being unusable.
• account:* being denied results in, for example, GetAlternateContact requests failing.

[goruha]

@Nuru @aknysh could you review this PR pls

[mergify]

Thanks @BFarand for creating this pull request!

A maintainer will review your changes shortly. Please don't be discouraged if it takes a while.

While you wait, make sure to review our contributor guidelines.

Tip

Need help or want to ask for a PR review to be expedited?

Join us on Slack in the #pr-reviews channel.

[Nuru]

@BFarand Thank you for this contribution.

I am going to close this in favor of PR #50, which incorporates some, but not all, of your changes.

SCPs are supposed to be restrictive, so I want to error on the side of them being overly restrictive. People are free to copy and modify our SCPs if they want to relax some restrictions; I am uncomfortable doing that for them. I did, however, add account and artifact as service exceptions for region restrictions.

• sso can be provisioned in a region, so I did not add that.
• Lambda region restrictions are tricky and I do not want to spring that on someone by changing the existing policies.
• Many S3 actions are region-specific, including creating a bucket, so I did not relax those restrictions.
• Access Analyzer and SSM are also region-specific and so I did not add those services to the list of exceptions.

I think, in general, it may be asking too much to try to prevent people from provisioning resources in us-east-1 since there are so many special cases of resources that must be provisioned there (e.g. ACM certificates, Lambda@Edge). So if the region restriction policy is too restrictive for those special cases, just add us-east-1 to the allow list. Otherwise we may need a whole new set of policies to deal with all the special cases.

After PR #50 merges, if you still want changes, I suggest you create a separate set of new policies where the global restrictions are relaxed and then individually tightened up, as you did here with Lambdas. Maybe just create a separate statement for the services that need us-east-1 that ensures they are enabled in that region, and then people can choose.