Is it possible to start AWS SCP with a default blacklist--and incrementally add rights?

Question

In a Pluralsight SCP course I'm working through, the instructor (Brian Eiler) described the normal state of affairs (with the Root having AWSFullAccess), but then went on to say that it could be handled the other way around–that it's possible to give the root account an SCP that grants nearly nothing and have child OUs/Accounts add permissions to that minimal set.

For learning purposes I thought I'd try this out. I proceeded as follows.

I created a new SCP: No-op

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Effect": "Allow",
      "Action": [
        "iam:GetLoginProfile"
      ],
      "Resource": "*"
    }
  ]
}

I added this No-op policy to the Organization Root account and then detached the standard FullAWSAccess SCP.

I next proved out that a user with full account rights could not list, let alone create, an EC2 instance in an account under the organization named Fun-One. So far, so good.

I then created a new SCP policy: Allow-EC2

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Effect": "Allow",
      "Action": [
        "ec2:*"
      ],
      "Resource": "*"
    }
  ]
}

I added the Allow-EC2 SCP policy to Fun-One and expected that admin user to now be able to list and create EC2s.

Not so.

I tried many things. Nothing worked. But when I added the Allow-EC2 SCP to the root OU, the admin user was able to list and create EC2s in Fun-One.

So it appears the tale I was told is not true. I've provided that material (down below) as an "answer" to this post.

My question is this: who is confused? Me? Or the instructor?

POSTSCRIPT:

Rohit's answer matches my experience. If Service X is denied (even implicitly) in OU A, then no child OU/Account under OU A can ever permit Service X. End of story. What the instructor said is simply not true.

Answer 1

You are correct if there is deny at organization level, it won't check anything downwards.

Default Way - Restrict S3 Access for an Organization Unit:

• you already have FullAWS Access in SCP
• restrict S3 Access by adding DENY S3

You can Implement otherway around: For Example: I have an OraganizationUnit where I only want S3 Access:

• I will remove FullAWSAccess and only Allow S3 Access.

Facts to understand before designing these type of policies.

• Deny wins over allow, if in the same policy you have a deny statement and an allow statement for the same service/action, DENY WINS.
• if you won't allow, it will be considered deny.
• you must understand why these policies are used at given stage, for example Organization Unit SCP is to control various services at account level. If an organization unit must only read data from S3 and won't update, I will only allow read for that organization unit.
• you must understand implicit and explict deny that I have mentioned at the bottom of this anwser.

I think better way to design policy approach is to understand policy evaluation logic.

I use this diagram before designing any policy, more details are here in aws documentation

Further There are two type of denies:

• Explicit: when you mention deny in the effect of policy
• Implicit: when you mention allow in the effect but operation that is not mentioned will be considered as implicit deny.

Answer 2

This is the reason for my OP, as I was trying to replicate what was explained below. I am curious if anyone else reads the below differently. In hindsight, it looks entirely wrong, to me. The text and image below are from a Pluralsight course taught by Brian Eiler. Thus far neither Mr. Eiler nor Pluralsight have addressed my questions regarding these dubious instructions.

On the other side of this we have whitelisting. Now whitelisting means we need to get rid of that FullAWSAccess policy that's at the very top, and we're going to put explicit allow policies as the SCPs at different levels. Here's a very big note just to make sure you remember this, you have to have a policy at the root. So to detach it, you have to create a new SCP, then attach it to the root, then you'll be able to remove the default one, but otherwise, you just won't be able to do it because there always has to be a default policy. So here we have our whitelist example. We'll start off, right now we can see that we have full access because we have the all actions permitted by that default policy, and the sequence of this is crucial to understand. You start off like this. Now we're going to create a new policy indicated by that gray marker, and we're going to say that that is our minimal SCP. It basically has the bare minimums to allow us to work in the organization, but it doesn't include any rights to work with the AWS services. Once we have that set up, I can now make that gray policy my default, and I can detach the AWS-managed policy, and the moment I do that, it detaches that policy from all of the other sub objects or the children objects that are here. Now what we'll do is the policy evaluation goes down, and because the gray policy doesn't specify any allows for the services, the effect is everything is denied. So far, so good. Now what we're going to do is go in and create our individual allow policies, whether it's on individual projects or accounts, or OUs, whatever you've done, we're going to create policies that will allow certain actions, but if we didn't allow it in those SCPs by default, it's not possible. This is closer to what you do, say, in a firewall. You deny everything by default, and open up holes where you need to.