Welcome back, everyone. Before we get started, let's first define three concepts, an explicit deny, an explicit allow, and an implicit denying. And in IAM policy, you use all of these concepts to determine an identity's level of access. Explicit denies and explicit allows our stated clearly in a policy. For each of them, you would see the words allow or deny in the policy. However, let's say you want to deny your user access to everything in your AWS account, except for a single S3 bucket. Do you have to explicitly deny every other action they can take in the console? No, instead, you can allow them access to that S3 bucket and then AWS will implicitly deny access to all other resources not mentioned in the policy. So if a policy does not have an explicit deny, or an explicit allow, it is implicitly denied by default. Okay, now that we know that, let's start with a scenario. Let's say that in IAM user named Bob makes an API call to create an EC2 Instance. AWS has to evaluate whether this API call is allowed or denied. To do this, AWS needs all of the information associated with this request to help them evaluate whether Bob can create an instance or not. AWS evaluates whether the request is allowed or denied by going through a series of checks. The first thing it looks for is if the request was made by the AWS root user. If it was, then the request is allowed because the root user has access to everything and that access can't be limited with IAM policies. However, in our case, we know that Bob is an IAM user, so that doesn't apply here. The next thing AWS looks at is the policies attached to Bob and the group the Bob is in. AWS parses through the policies using evaluation logic to determine if the request is allowed or not. AWS first asks, is there any explicit deny in any of these policies? If the policy explicitly says that Bob can't create an instance, then the request is denied. If there's no explicit deny, AWS then ask, is there an explicit allow in any of these policies? If there is a statement that says Bob is allowed to create an instance, then their request is allowed. If there's no explicit deny, or explicit allow, then Bob is implicitly denied from creating an instance. I personally like to call this logic the go ask your mom logic. When a kid wants to go do something, they'll go ask whichever parents is most likely to say yes. Say, in this case, it's their mom. So the kid goes and ask their mom to do something and the mom might say, I don't know, go ask your dad. And so the kid goes and ask the dad and the dad says, I don't know, go ask your mom. And the kid is thinking, well, I didn't get a note from mom and I didn't get a note from dad. So I guess that means, yes, I can go do the thing that I want to do. Well, not in IAM. In IAM, if you don't get an explicit yes, then you cannot do that thing. The kid is stuck until they get a yes. Furthermore, if mom says yes and dad says no, the no will win over the yes every time in IAM policies. Okay, now that we have that down, let's look at a few examples of policies that I could attach to my user, Bob. The first policy looks like this. I encourage you to pause the video and take a few seconds to figure out what actions Bob can take and what actions he can't take. In this example, Bob is allowed to access the specific S3 bucket called policy example buckets, where Bob can list all of the objects inside of that S3 bucket, as well as read and write to that bucket. So does that mean that Bob is allowed access to other S3 buckets that are not mentioned in this policy? No, because access to all of the resources not mentioned is implicitly denied. The other policy I have attached to Bob looks like this. Go ahead an pause the video and determine what Bob is allowed and not allowed to do, and make sure you take into account both of these policies that I've shown. So to determine what Bob can do, let's go ahead and use our flow chart steps. The first thing will look for is an explicit deny, and both of the policies. You can see an explicit deny that says Bob can't list the policy example buckets. Then we look for an explicit allow in our policies. In the last policy example, Bob had an explicit allow to list out that same as three buckets, the policy example bucket. So here, we have conflicting statements and AWS has to figure out which one wins. Well, to be safe, AWS decided that even if I have an explicit allow, the explicit deny always wins, okay? So remember that an explicit deny will always override an explicit allow, which means Bob cannot view this particular bucket. The same can be said for how identity policies and resource policies work together when an IAM identity such as a user or role request access to a resource within the same accounts. AWS evaluates all the permissions granted by the identity-based and resource-based policies. The resulting permissions are the total permissions of the two types. If an action is allowed by an identity-based policy, a resource-based policy, or both, then AWS allows the action, except if an explicit deny isn't either of these policies and then that will override the allow. That's all we have in this video. I hope you had fun and I will see you in the next one.
