‫So going into the exam,
‫we need to have a much better understanding
‫of advanced IAM concepts.
‫So this lecture is going to be dedicated
‫to explaining to you a few things
‫that you think are granted
‫but it's always good to see them outlined in diagrams.
‫So the first one is the authorization model
‫and how policies are evaluated.
‫So since this is a simplified model by the way,
‫it's a lot more complicated,
‫but hopefully that gives you a good idea
‫about how that works.
‫If there's an explicit deny in your policy
‫then you end the decision with a deny.
‫If there's an allow, you end the decision with allow.
‫And else, you deny.
‫So what does it look like?
‫Say for example, that a user wants
‫to create a DynamoDB table,
‫the decision starts with deny.
‫So by default, it can't do it.
‫Then all the policies attached to that user
‫will be evaluated.
‫So for example, if we have a policy attached to our user,
‫this will be what goes into this all applicable policies.
‫Then we'll look at the policy.
‫Is there an explicit deny in the policy?
‫Is there somewhere in the policy
‫that says, "Users cannot create DynamoDB tables"?
‫If so, the final decision is deny, no matter what.
‫Then, only then, the allow will be evaluated.
‫So is there an allow statement,
‫allowing the user to create a DynamoDB table?
‫Yes, then the final decision is allow.
‫No, then the final decision is deny.
‫So if there's both an explicit deny
‫and an explicit allow in the policy,
‫as you can see the deny will win
‫because the explicit deny condition is evaluated first.
‫So remember that diagram, it's really important.
‫Now comes the fun part.
‫How does IAM policies work with S3 bucket policies?
‫So IAM policies, we know they're attached
‫to users, roles and groups,
‫whereas S3 bucket policies,
‫they're attached to buckets
‫and they both define what users can do on the bucket.
‫So when we evaluate in IAM,
‫IAM principle maybe can put an object into an S3 bucket.
‫What will be evaluated is the union
‫of the IAM policy and the S3 bucket policy.
‫So this is something that is not really well known.
‫So if you take an action in S3,
‫you look at the IAM policy plus the S3 bucket policy
‫in union together, so all these rules are added together
‫and that will give you the total policy
‫that will be evaluated from a security standpoint.
‫Something to know about.
‫So that means that, for example,
‫if you have an EC2 instance
‫and you remove the S3 policies in the IAM policy,
‫but there's still an S3 bucket policy
‫authorizing the EC2 instance to do something,
‫then it will still be able to do stuff in S3.
‫So very important to know this.
‫Let's go through four examples
‫just to make sure this is really really clear
‫and pause the video if you need to
‫just to make sure you understand correctly.
‫So say you have an IAM role attached to an EC2 instance
‫and it authorizes reads and writes to my bucket.
‫There's no S3 bucket policy attached.
‫In this case, can the EC2 instance
‫write and read to the bucket?
‫Yes, it can.
‫Because the union of these two things,
‫is that our EC2 instance has the right
‫to read and write to my bucket.
‫Okay, second example.
‫We have an IAM role attached to the EC2 instance
‫and it authorizes the read writes to my bucket
‫but this time, the S3 bucket policy
‫is attached to the S3 bucket
‫and there's an explicit deny to the IAM role
‫used by that EC2 instance.
‫In this case, is the EC2 instance allowed or denied
‫to write to the bucket?
‫Well it cannot read from the bucket
‫because there is now an explicit deny in the union policy
‫and we've seen that explicit denies
‫have higher priority than explicit allow.
‫So in this case, our EC2 instance
‫cannot read and write to my bucket.
‫Example three.
‫We have an IAM role attached to the EC2 instance
‫and there's no such thing as S3 bucket permissions in it.
‫It's an empty role.
‫And from the S3 bucket policy
‫that's attached to the S3 bucket,
‫there's explicit read write allow
‫to the IAM role used by the EC2 instance.
‫In this case, can our EC2 instance read and write
‫to our bucket?
‫The answer is yes, it can
‫because the union policy, again,
‫has the read write allow from the S3 bucket policy
‫and so our EC2 instance,
‫even though within its IAM role
‫it's not specified that it can do stuff in S3,
‫the S3 bucket policy will still allow this
‫and so our EC2 instance can read and write to my bucket.
‫Last example, the IAM role attached
‫to the EC2 instance has an explicit deny
‫and the S3 bucket allows it, in which case,
‫well then you probably know the answer to that,
‫the EC2 instance cannot read and write to my bucket
‫because of that explicit deny.
‫So hopefully through those four examples
‫it makes it more clear about how policies are evaluated
‫when you have both an IAM role and an S3 bucket policy.
‫Now let's consider another advanced IAM concept
‫called dynamic policy.
‫So how do you assign, for example,
‫a /home/ user folder in an S3 bucket,
‫such as each user in your IAM organization
‫will have their own folder
‫and can read and write to it only?
‫Option one is, for example,
‫you can create an IAM policy allowing your Georges
‫to have access to /home/georges.
‫Maybe you create another IAM policy
‫allowing your user Sarah in IAM
‫to have access to /home/sarah.
‫And maybe do this thing for Matt, /home/matt.
‫So you'll have one IAM policy per user
‫and every time you add a new user,
‫you will have to create an IAM policy
‫allowing them access to their own home directory.
‫So this doesn't scale obviously, right?
‫Option two is, as you can expect,
‫using dynamic policy in IAM
‫and just creating one of them.
‫And you will leverage a special policy variable
‫called ${aws:username}.
‫And this at runtime, because it's dynamic,
‫will be replaced by the value of the AWS username.
‫So now what you can do is that if you want
‫to allow your user to write to their own folder,
‫you can just have this very simple dynamic policy
‫in which you say, and you can attach this to all users,
‫you're saying that you have the right
‫to access /home/${aws:username}
‫And that's it, very simple
‫but now that you know that dynamic policies
‫and dynamic variables exist within IAM,
‫it expands the possibilities of IAM so much.
‫The idea is that you don't want to have one policy per user,
‫you want to have one policy for every user
‫yet that is customized on a per user basis,
‫thanks to the replacement dynamically of the AWS username.
‫Last but not least, let's talk about the difference
‫between inline and managed policy.
‫So there's three kind of policy in AWS.
‫There's the AWS managed policy
‫and as the name indicates, they're maintained by AWS,
‫you don't have any control over them
‫and they're good if you want to define power users
‫or administrators or based on job functions.
‫And they will updated by AWS
‫in case they create new services
‫or they introduce new APIs.
‫So they're very helpful
‫if you want to have your administrators, for example,
‫and we've been using those all along.
‫Then you have customer managed policy.
‫This time, it's you who create these policies
‫and it's best practice to use them
‫if you want to have more granular control.
‫They will be reusable, they can be applied
‫to as many principles as you want.
‫They will have version control,
‫you'll be able to rollback these policies
‫if you want to in time.
‫There is a central change management
‫so you can see who did what and whom.
‫And they're great and by the AWS documentation
‫they are best practice.
‫Finally, you have inline policy
‫and the inline policies are directly within a principle.
‫They're strict one-to-one relationship
‫between the policy and the principle.
‫They're not version control, you cannot roll them back,
‫you cannot really alter them very easily.
‫And if you delete the IAM principle,
‫the policy will be deleted.
‫So remember the differences between these three.
‫Let me just show you how they are in the IAM console.
‫So here I am in AWS IAM.
‫And so on the left-hand side, I can click on Policies
‫and here I'm able to see all the policies
‫that have been created.
‫So I can filter them maybe by AWS managed policy
‫and here we go, we can for example see
‫that this one is AlexaForBusinessFullAccess
‫or AlexaForBusinessReadOnlyAccess
‫and you have those for pretty much every single service.
‫So if I typed DynamoDB, I see all these kind of policies.
‫We have DynamoDBFullAccess,
‫DynamoDBFullAccesswithDataPipeline,
‫ReadOnlyAccess, Autoscaling, Lambda,
‫all that stuff, and the ReplicationService.
‫So we can very quickly see all the policies
‫and as you can see, those are AWS managed.
‫You can also see your customer managed policies
‫and they're the one,
‫and let me remove the filter,
‫they're the one that we have created through this course.
‫So we have some CodeBuilds, CodePipeline, Lamda and so on
‫and these are customer managed.
‫So if I click on one of those, for example,
‫I can see the permissions
‫and I could see the version, the policy version
‫so in this case there's only one version
‫and I can see the policy usage,
‫meaning what is using this policy.
‫So it makes it very easy and auditable
‫and customizable at the very same time.
‫Finally, there's inline policy
‫and you will not find them here.
‫You will find them in your Users, in my name
‫and here on the right-hand side,
‫I'm able to add an inline policy through the service,
‫for example EC2, and give myself list permissions.
‫Now I want to show you something
‫so I'll say, "Okay, list permissions."
‫And there's 95 of those selected
‫and this is excellent.
‫On the Resources, I don't need to specify any resource.
‫So I click on Review policy
‫and I'll call this MyInlinePolicy
‫and click on Create policy
‫and something you'll notice right here
‫is that I cannot create this
‫because my policy max bytes is two kilobytes
‫and it's been exceeded for this user
‫so by using an inline policy
‫you're actually not able to specify
‫many many different things.
‫So in this case, if we go previously
‫and look at the JSON,
‫as you can see there's a lot of different text
‫and that probably goes over two kilobytes
‫so I cannot use this policy.
‫Instead I could, instead of using List,
‫select one of these attributes
‫and now hopefully my inline policy will work.
‫Yes, it has worked.
‫And as we can see now,
‫I have now attached to my own user MyInlinePolicy
‫which is an inline policy.
‫And from there it is actually linked to my user
‫but as you can see it's not very handy,
‫not very auditable and it has some restrictions in size.
‫So that's it, I hope that was helpful.
‫I hope you learned a lot in IAM
‫and that you'll use those concepts accordingly
‫and I will see you in the next lecture.