The S3 resource access security policy diagram, presented at 3:30 in the "S3" lecture looks wrong to me.
The diagram shows, that if there’s no IAM policy allowing access to an S3 resource for a user, that user is immediately denied access.
But my understanding is different.
In the Re:Invent video linked in this lesson’s pro-tips "AWS re:Invent 2018: [REPEAT 1] Become an IAM Policy Master in 60 Minutes or Less" https://www.youtube.com/watch?v=YQsK4MtsELU
At 12:30 she says "If you are within an account, you need either IAM policies to say yes or resource-based policy to say yes".
So – and I think this is the trick – as long as there is not an explicit deny in the IAM policy to deny access to the S3 resource, even if in the first box of the diagram showed in the lesson, the user is not explicitly allowed access to the resource, the access is not denied at this stage of the permission evaluation.
The way it is presented it really looks like you need both an allow policy in the IAM policy and the resource policy.
I think a more accurate diagram would show a first box saying something like "is your user explicitly denied to access me?" and inverse the "yes" and "no" arrows.
It feels like a subtle but yet very important nuance.
Not sure I completely follow but do remember that every IAM user in an account has implicit deny to start with, so if there isn’t an explicit IAM policy granting access, you don’t get in.
You can read about all this here: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html#policy-eval-denyallow
Hello Scott, my understanding is slightly different – but I might be wrong. In fact, I think it might just be the wording in that diagram that is confusing. So, correct me if I’m wrong. Before taking a decision on grating access or not – all – policies (SCP, IAM, S3 bucket, other resources policies, session policies…) are evaluated. Then if none of these policies grant any access, then it defaults to deny (which is very different than saying that an IAM policy/user defaults to an implicit deny). In that same video mentioned above, at 14:08 she gives a challenge with an SCP allow policy, no IAM policy and a resource-based allow policy and the result is an "Allow". Not a "Deny". Let’s take another example – within a same AWS account: 1- A user account is given an IAM Role with no explicit deny/allow to an S3 bucket. Now let’s say that that user’s Role is given the tag "Project Blue" (or the user gets that tag as a session tag). 2- The SCP allow S3 in the scope of access for the account that that user belongs to. 3- The S3 bucket policy grants access to Principals having the tag "Project Blue". My understanding is that – when within the same AWS account – the user will be granted access. So the user IAM policy is not granting that user any access to the S3 bucket, yet the user will be granted access. Going back to your diagram: in the first box, despite the IAM policy doesn’t give access to the S3 bucket it doesn’t go the "Get Lost!" stage. I may be improperly reading the first box, taking "user account" for "IAM policies" and we could maybe answer "yes" to the question "is your user account allowed to access me", because it is in the bucket policy, but then the second box about the bucket policy is irrelevant. It might just be me but I find the whole diagram unclear and confusing.