Maybe I’m not understanding your affirmation but AFAIK, SCP are similar to IAM policies in the way that you can Allow or Deny specific Actions on specific services, so when you say that they can only deny access, are you saying they can only Deny Actions? or what access are you talking about?
2 Answers
I think what Faye was trying to get across is that SCP’s can only effectively deny actions. If you have an SCP which explicitly allows an action, you would still have to allow that action with an IAM policy in a child account. Whereas if you had an explicit deny in the SCP, the action would be denied regardless of whether the IAM policy in the child account explicitly allowed the action. As Organizations applies a full access SCP by default, the easiest approach to take is a blacklist approach to SCP’s where you would explicitly deny the actions you don’t want to be performed by any role, or user in the child OU or account. This doc site might be of use: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_example-scps.html
Hopefully that answered your Q 🙂
By default everything at the Root level of your Organization is implicitly allowed by the SCP (i.e. nothing is denied) and you then configure the SCP to deny only the actions that you want to restrict. This is the default behaviour when you configure an SCP and when you are using an SCP to create a permissions boundary. So by default you cannot "allow" anything because all actions are already allowed, so you can only deny.
However, it is technically possible to alter the default configuration… by adding explicit allow statements to the root level SCP. But if you start adding allow actions here, that implicitly means that any action not explicitly allowed else would be implicitly denied. – This is a much more complicated way of doing things though and it would be a big overhead to create a permissions boundary in that way. It is also pretty dangerous because you can end up restricting what can be done at the root level of your accounts…so you do need to be very careful if doing that! (and that is also not a recommended way of creating a permissions boundary)
When using an SCP to create a permissions boundary, it’s much easier to slap a deny on the services you want to restrict access to at an OU or account level…and easier to audit, update, manage etc.
And finally the SCP is always evaluated in the context of the other IAM policies and resource policies within the account as well… so an action would need to be allowed by local IAM and resource policies (e.g. S3 bucket policies, KMS Key policies etc) as well as not being denied in the SCP.
I hope that helps, I might review that lecture and see if I can make it a bit clearer if it is coming across as confusing.