Amazon AWS Certified Security Specialty – Domain 4 – Identity & Access Management part 6

13. IAM – Version Element

Hey everyone and welcome back. Now, in today’s video we will be discussing about one of the first I am policy elements of version. Now, generally, whenever you go ahead and write I am policies, there are various elements that you make use of. Like you have version, you have statement here, you have action, you have effectively resources and others as well. So these are referred as the policy element. It is important for us to understand at a high level overview about these because in exams if you get some questions related to troubleshooting of im policies, having a good understanding of the policy element proves to be quite useful. So let’s go ahead and understand more about it. So, speaking about the version element, a version element basically defines a version of your policy language.

Now, the overall syntax rules for your im policy can differ based on the version of the policy language that you make use of. Now, one simple syntax for the version element is you specify a version followed by the version which is available for the IAM policy. Now, there are two supported version element values. The first is 2012 hyphen 1017 and second is 2008 Hyphen 1017. Now, you can just remember it as 2008 and 2012. Now, as expected, 2012 is the current version of the policy element for version and it is recommended to always define the version element to 2012 Hyphen 1017. Now, you also have 2008. Now, 2008 version is the earlier version associated with the policy element and you should avoid defining this version in any of the policies.

However, you can see in certain policies which are quite old, which has the older version which is defined. So you have to make sure that you change that version with the latest version over here. Now, one very important part to remember here is that if you do not include a version element within your im policy, your IAM policy will default to the 2008 version. And this is the reason why in the second point here, it is mentioned that it is recommended to always define the version element as 2012 because if you do not define it, your im policy will be evaluated based on the version 2008. Now, one of the question that comes is what is the advantage of using 2012? Why can’t I go ahead and use 2008? Now, the answer to this is there are certain aspects within the im policy which are only supported within the latest version.

Those aspects are not supported within the older version and this is the reason why you should always define the latest version. However, let’s jump into the practical to understand this before we move further. Now, I have a simple im policy over here and this im policy basically allows the user to generate operation related to access key so he can manage his own access key over here. All right, now within year you have a variable over here you see, this is a variable. We’ll be discussing more about this in the upcoming video. But this is a variable that is defined over here. Now, this specific variable is only supported with the latest version, it is not supported with the older version. So let’s look into the practical aspect to understand it in a better way.

So I’ll copy this policy and I have an Im user called as demo user and we’ll quickly create an inline policy here. All right? So this is the inline policy. Now, before we go ahead and attach it, currently in a second console, I am also logged in as a demo user over here. So now let’s go ahead and create an access key and you see it is basically giving you an access denied operation which basically means that the demo user does not have permission to create his access key. Now, within the policy we are already giving him the allow effect on the action of access key so he’ll be able to manage his keys. So let’s go ahead and review the policy. Let’s call it as demo policy and I’ll go ahead and I’ll create it. All right? So we have a demo policy attached to the demo user and again if I create access key as expected, the demo user is able to create his or own access key.

So you can also go ahead and delete the access key. So basically the demo user will be able to manage his access key. Now let’s go into the policy, let’s edit it and let’s change it to 2008. All right, we’ll change it to 2008. I’ll do a review policy and I’ll click on save changes. Now, within the demo user let’s click on create access key and now you see you immediately got a permission denied that a user is not allowed to perform a create access key permission. All right? So basically this specific variable over here which are also referred as the policy variables, this is not supported in the 2008 version, it is only supported with the latest 2012 version. Now, in one of the organizations that I have been working with now this was quite long ago, so a team member came to me and he was basically trying to attach a similar policy which made use of policy variables.

However, he had made use of the version 2008 within his policy code and he was not able to figure it out because he was trying it since a lot of time but the policy was not working. So he verified everything, he verified the action element, he verified effect, he double checked on the resource but still it was not working. The only thing that he had missed here was the version element. So changing it from 2008 to 2012 worked wonders. So you have to make sure that whenever you get certain troubleshooting scenarios you have to also take into the consideration the version element because this also proves to be an important role. Now, the thing that it makes more confusing is because your IAM policy here it will accept even if you specify 2008 using certain features which are not supported, your policy editor will go ahead and accept it right away.

So initially you might find that this policy is quite good enough. But although this policy is attached, it will not do the work as intended. So I hope you understood the difference at a high level overview about the version element and also that you should also explicitly specify the latest version. Now, before we conclude, let’s look into some of the important pointers. Now, the first one is that version element is not equal to policy version. Now, do remember that a version element and policy versions are two different aspect altogether. So you should be aware to not get confused with the names. Now let me quickly show you. So I’m in my AWS IAM console. Let’s go to policies here and let’s click on create a new policy. I’ll go to JSON and within here we’ll copy the im policy that we have. I’ll copy it. Let’s go to review and the name, let’s call it as Kplabs policy. I’ll go ahead and create it.

All right, now let’s go to the Kplabs policy here and this is the policy that we have. Now, within this policy you have the version element here. So this is the version element. Now, you also have a tab called policy version. Now, what happens is that whenever you make a change to your policy, your policy version gets incremented. Now let me quickly show you. So within the policy version you only have one policy version which is available. So let’s go ahead and edit this policy and let’s change the effect from allowed to deny and I’ll save the changes. Now, as soon as I make a change to my policy, you will see that your policy version has incremented. Now here the version two is marked as default. That basically means that this denied that we had made in the second increment is currently the default policy.

Now, it also maintains the version. So you can also see what was there before you made the change and you can even set the earlier policy to the default one. Many times what happens is that when you make change to the policy a lot of things can break. So in that case you want to revert back to the previous working version. So this versioning helps quite a lot here. So you can go ahead and select the older version, you can set it as default. And now again, if you’re you see within the permission you have the effect of allow. So this is a difference between the version element and the policy version. So a version element, as we know it specifies the language of the policy and the policy version basically is like a versioning of your im policy that you attached or modified?

14. IAM Policy Variables

Hey everyone and welcome back. Now, in today’s video we will be discussing about the IAM policy variables. Now, the policy variables are generally used when you do not know the exact value of a resource or a condition key whenever you are writing a policy. Now, for example, here, this is a simple ARN here and for the user with a slash you are making use of a variable over here. So policy variable is basically the variables which you define within the policy. So this specific variable block will be computed at a later stage. So this block remains to be a variable. Now, during our video of version element we had taken a specific IAM policy where we made use of a policy variable over here.

Now let us understand what is the advantage of using a policy variable and if we do not make use of a policy variable, what is an alternative? Now, I’m in the IAM user and we have a policy which we had attached called as the demo policy. Now, if you look into the demo policy over here, let’s go to the JSON element. This is the policy that we had attached. Now, if we would have not attached this specific policy which is making use of a policy variable, then you would essentially replace this specific stanza with the name of the IAM user. In our case, the name of the IAM user is demo user. So let’s try it out along with that. Let’s just replace this with 2012 and let’s review the policy. I’ll click on save changes.

All right. So now you have this specific ARN associated with the demo user and it has the action associated with access keys so that the demo user can manage his or her access keys. Now, just to verify if things are working perfectly or not, I am logged in with the demo user and let’s click on create access key over here and as expected we are able to create the access key. Now the question comes is what is the advantage of using a demo user here or what is the advantage of using a policy variable? Now, when you make use of a direct ARN over here so in this case, this is the ARN associated with the IAM user.

So when you make use of this ARN directly within the policy, that would typically mean that this policy cannot be reused. This policy can only be attached to the demo user. Now let’s say that you want to attach the same policy because you can make this as a managed policy and you want to attach this policy to ten different users. Now you cannot directly make use of this policy and attach it to ten different users. So let’s say there’s a user name as Alice. Now, if you attach this policy to the Alice user, the policy still has the ARN associated with the demo user. So Alice user will still not be able to perform the operations with the access key over here. So that is a problem.

Now, when you make use of this kind of a scenario, let’s copy this back. So when you make use of a policy variable over here, irrespective of which user you attach, because this aspect is a variable, you attach it to the Alice user, then this would become Alice. If you attach it to the Demo user, then this variable will change to demo and so on. So whenever you make use of a policy variable, that basically means that you can go ahead and attach it to the entire group of 100 Im users as well. And it will work pretty well because you have a policy variable which is attached within the IAM policy. So this is a good use case about policy variables and generally within the organization you will will be making use of this specific policy variable quite extensively.

15. Principal and NotPrincipal Element

Hey everyone and welcome back. Now in today’s video we’ll be discussing about the principal and not principal element. Now principal element is generally used to specify things like I am user federated users, I am role AWS account AWS services and so on within your policies. Now generally the principal element is used with the resource based policy or with the trust policies. They are not used or they cannot be used with the IAM identity based policies. The reason why they cannot be used is because the identity based policies are directly attached with the specific identity there. Now this is a simple syntax where you have a principal limit and you are specifying the ARN of a specific user. So in this case you have a route but you can also define specific user like Alice, John, et cetera.

Now, during the video of identity versus resource based policies, we were discussing about this specific example where there are certain identity policies attached to the im user and there are resource policies which are attached to a specific resource. And we were discussing about what would be the end effect of it because there are certain policies attached to the identity, certain policies attached to the resource. So what is the end result of that? So what we’ll be doing today, we’ll be taking an example of one of these in today’s demo. Now for Alice user, we had already discussed that Alice user had read and write. Now for the John user here if you will see John user has no IAM policy which is attached to it.

However, at the resource base policy John user has full access. Now within here the final operation that John will be able to perform is full access even though there is no im policy which is attached to it. So the question is how can we mention each user within the resource based policies and specifying this user within your resource policies can be achieved with the help of principal element. So let’s jump into the demo and look into how exactly it might look like. Now for today’s demo we have a sample s three bucket policy which is available and within this policy we have a principal element here.

Now within the principal element we have added the ARN associated with the Alice user, mentioning that Alice user will be able to perform all the s three operation on a specific s three bucket. Now if you look into the Alice IAM user here, you will see that there are no IAM policies which are attached to it. Not Alice user is under any group so there are no permissions which are attached. Now this is very similar to the user John over here where there is no policy which is attached to the IAM user John. However, for the s three bucket you have explicitly allowed the John user for the full access. Now if you look into this s three bucket, if I go into the permissions.

And if I go to the bucket policy, you see that this is the exact bucket policy that we had seen within the atom editor, where within the principal element we are specifying the ARN associated with the Alice user. And the outcome of these two policies is that in this diagram John will have full access, in our case Alice will have full access. So currently I am in a Linux box and I have already configured the Alice’s key within the terminal. Now from Alice key, if you quickly do AWS s three LS on the bucket name, the demo s three bucket, you see Alice user was able to successfully list the files. Now this is just one example, you can even upload file, you can delete file. Basically you can have access to all the operations which can be performed.

So in this case if you do not want Alice user and if you want a different user to have permission, you can basically specify within the principal element the ARN of that user. So I hope you understood the importance of principal element within a resource based policies. Now again principal element can be used within the trust policies as well. But just remember at a high level overview what principal elements are all about. Now the principal element can contain various aspects. One is the im user that we were just discussing in today’s example you can even have im role, you can even have the service name. So you can even specify which service can access your s three bucket and which service cannot.

So this is a simple example where you are defining data pipeline, Amazon, aws. com, so even this aspect can be considered within the principal element. You can even add federated users as well. Now, similar to the principal element you can also have not principal element. Now, when you make use of a not principal element with the effect of deny, then that basically means that the actions which are specified within the policy statement are explicitly denied to all principles except for the ones which are specified. This is important and you should understand the use case that we are discussing here for not principal element and as well as for the principal element use case that we just discuss.

Now within this specific bucket policy you see that there is an effect of denying and you have a not principle here. That basically means that apart from these two principles everyone would be denied for all the actions on SC bucket and this is the bucket name and that basically means that Bob and Alice will be allowed and apart from that everyone else will be denied. So this is the not principal element to warrior. Now, within the principal element where we were discussing here, this basically means that Alice user will be able to perform all the operations on the s three bucket even though Alice user does not have any im policy attached to it. However, if there is a user Bob who has an S three full access, even user Bob will be able to perform all the operations on this specific S three bucket.

We are not denying any other principle from doing operations on this S three bucket. We are just explicitly allowing the user Alice to perform the operations here. So this means that not only Alice but even other im users, if they have a proper identity based policy, they will be able to perform the operations in this bucket. However, in this specific use case of not principal element, even though there is an administrator user, he will not be able to perform operations on the S three bucket because there is an explicit denial which you are specifying within the resource element. All right? So make sure that you understand these type of policies.