Question 318472 in Amazon Web Sevices Question posted in
The official Amazon Web Services documentation can be found here.

Amazon web services – Is it possible to start AWS SCP with a blacklist instead of a whitlelist approach

I am learning how AWS SCPs work, and the explanation I heard from the course I’m going through was this: you start off with a default "Permit everything" SCP policy in the root of the organization, and then remove permissions as necessary. Anything removed at any level makes the permission removed impossible to grant via internal account policies. Fine.

The instructor went on to say, however, that it’s possible to start off the other way around. That is to say, give the root account an "empty" SCP which denies nothing but which also grants (more or less) nothing. From there you can add permissions as you wish. So 3 nodes down in the org tree you could grant, for the first time, EC2 permissions to an account.

So for learning purposes I thought I’d try this out. I created several new SCPs.

Name: No-op

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

(I gave the iam permission shown because I couldn’t figure out how to define a true no-op SCP that, in fact, neither grants nor denies anything.)

I added this No-op policy to the Organization Root account. There now being 2 policies present, I was permittted to remove the standard one, which for completeness I’ll provide here:

Name: FullAWSAccess

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

Next I created yet another policy, just for playing around.

Name: Allow-EC2

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

Finally I went down an OU node and logged in to an Account (which we’ll call Fun-One) as a user with full rights (the AWS policy AdministratorAccess, to be specific) in the account.

I couldn’t list, let alone create, an EC2 instance in Fun-One. Great.

Now I went back to Fun-One and added a new SCP to it: Allow-EC2.

I now returned to Fun-One hoping to see that my admin user would be able to list and create EC2s. Not so.

I tried many things. Nothing worked. Finally, out of desperation, I added the Allow-EC2 SCP to the root OU. Now Root has two policies, one of which grants EC2 rights.

I went back and hey-presto, now my admin user can list and create EC2s.

But this is not the version of the story that I was told.

To be clear, I don’t wish to defend a need to start an AWS organization with a blacklist SCP approach, where permissions are only added in downstream. I’m fine with going with the flow.

But for purposes of understanding AWS SCP logic, I have hit a brick wall. It looks as if AWS is ONLY designed to start off with everything granted, and we can then remove permissions downstream if we so choose. But to do the reverse? Maybe not.

Does anything I did look wrong? Or is my understanding of AWS SCP flawed? Or was that online instructor mistaken in what he presented?

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.

I’m also going to throw (down below) an "answer" that is what the course instructor taught, verbatim. I’m curious if anyone reads/hears it differently than I do.

Tags:

2

Answers


  1. Chosen as BEST ANSWER
    0

    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.

    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.

    enter image description here


  2. 0

    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

    enter image description here

    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.
      enter image description here
    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search