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

16. Implementing NotPrincipal Element

Hey everyone and welcome back. Now, in the earlier video we were discussing about a principal and not principal element. Now, within the not principle element, we discuss about a simple policy here which basically denies everyone except the Alice and the Bob user to perform operations on the S three bucket. So what we will do is we will do this in a practical way so that we understand about this policy in much more better terms. So let’s get started. Now, I have the policy within my item editor here. And if you will see that you have an effect of deny and you have a not principle where you are specifying the ARN of an IAM user. So let’s do one thing. Let’s copy this up. And I already have some random Sree buckets which were created by cloud formation earlier.

So we’ll be using this random bucket for our testing purpose. So let me go ahead and paste the bucket policy. Definitely we’ll have to replace the bucket name. So let’s quickly replace the bucket name. All right, so this is the policy that we have created. Now you can go ahead and you can do a save. Now, once you have done the save, you will get access denied whenever you try to do any operations on this S three bucket which is apart from the user Alice. So let’s go to overview. So let me quickly refresh the page because this is more of a cache. Now, as soon as I refreshed, you see, immediately it gave an error saying access denied. So even though I am logged in as a root account user, I am still getting access denied because this bucket only allows the Alice user to perform the operation.

Now, we already have an Alice Im user which is available now from the CLI. I already have the Alice’s key which is configured within my CLI. So if I do AWS S three LS and try to see the contents within the bucket where we have the bucket policy attached, you see, it gave an error about access denied. Now, if you would have seen that within the principal element when we had added allow over here, even though there was no IAM policy which was attached with the Alice user, the Alice user was able to successfully view the contents. However, for the denying effect, things are little different. Now, why they are different is because here for the Alice user, you are not explicitly adding a allow statement. So what will happen here is that you will have to add an IAM policy to the Alice user to be able to view the contents from the S three bucket.

So let’s quickly add a permission to the Alice user. We’ll add a simple S three read only access for the time being. All right? So now the read only access has been configured. So let’s clear the screen. And when I do a doublesse again, now you see Alice user is able to successfully list the contents. So I hope you understood what not principal element was all about. And also, while you are adding a deny, it does not mean that it is an explicit allow for user Alice. You have to add an explicit allow within the IAM policy as well in case if you have a specific s three bucket policy similar to what we were discussing right now. So that’s the high level overview about the not principal element in the practical way. I hope this video has been informative for you and I look forward to seeing the next video.

17. Conditionl Element

Hey everyone and welcome back. Now in today’s video we will be discussing about the condition element. Now, the condition element allows us to specify the conditions for when a policy is in effect. Now, we can understand this with a simple policy over here which states that allow full access to user Alice on EC two resource. So this is a simple statement only when a condition is met. So allow full access to Alice on EC two only when the following condition is met. And within the condition you are saying that date greater than then you have the AWS current time and then you’re specifying a time over here. So this basically means that only allow Alice full access to easy to resource only when the call, the API call is made on a specific date which is greater than the date that you have specified over here.

Now, I’ll give you one example because I have been using this kind of a policy quite extensively. So generally whenever we take an interview, there is a practical session. So it’s like a troubleshooting session where he logs into AWS and he performs certain troubleshooting tasks that we assign to him. So let’s say that there is an interview for a specific user at 04:00. P. m. . Now, the email for him to log into the AWS account is already shared 24 hours earlier with him. However, he will not be able to perform any operations like he’ll not be able to see anything in AWS unless and until his interview time has started. So within the current time you can specify, let’s say 04:00 P. m. , so he’ll be able to see the AWS resources only when the time of 04:00 P. m.

Which is his interview based practical starting time has been initiated. So this is one quick example where condition element proves to be quite useful. So let’s look into few more examples related to condition element so that it becomes easier for us to understand. Now, I have one more example, so this is quite a good example and you might see similar examples within the examinations as well. So it’s better to understand what this is. Now, this is very similar where you are basically have an effect of allow the action of star, the resource of star. So that basically means like this is a policy which gives administrator access to a specific user. However, there is a condition over here. The condition is that only if the IP address is the IP address which is specified over here.

So only give administrator access to an IAM principle when he meets the condition. So in this case, the condition is that his source IP should be the one that you have specified over here. All right? So this is the condition. So let’s do one thing, let’s try this out and look into how exactly it works. And within the Im console currently I am inside the user Alice. Let’s add an inline policy here. We’ll go to JSON. All right, we’ll add an inline policy. However, before we go ahead and review it, let’s quickly verify the IP address that we have. So the current IP address is little different. Let’s copy this up and I’ll paste the IP. Let’s go ahead and do a review. Let’s call it as conditional policy. Let’s go a bit down and create a policy. All right, so the conditional policy is created.

Now, since the condition already has the IP address, so we are already meeting this specific condition from the Alice’s users access secret key. We should be able to perform all the operations. So let’s try it out. So I’ll do. AWS s three alice So currently Alice’s access and secret keys are configured within my CLI and currently you see, you are able to see all the S three buckets as expected. So that basically means that the condition is working perfectly well. Now, let’s manually edit this policy. Let’s change the IP address a bit. All right, we’ll change the IP address and save the changes. So now since our IP address does not match the source IP here, that basically means that whatever permissions which are specified over here will not work.

So let’s clear the screen, let’s do AWS three LS. And now you see immediately you got an access denied message. So with this I hope you understood what condition element is all about. Now we have one more policy over here and here we have a condition of not IP address. So this basically means that allow full access on all the resource if the IP address is not within the range which is specified over here. Now, do remember that this is an entire subnet. This is not 32 CID. So this is an entire range of IP address which are specified over here. So you can also specify not IP address depending upon the use case. Now, you also have a third policy. So this is a sample policy, but you need to be aware about this where it says that a condition is present here which has AWS multifactor auth present as false.

So that basically means that if you look here the effect is deny. So that basically means that deny following operations on this specific Sree bucket if the user has not authenticated with the MFA. All right, so this is what this specific condition is all about. So whenever you go through the condition, also go through the action and the effect, then only you will be able to understand what the condition actually does. All right, so these are some of the sample policies that you need to be aware about on how exactly the condition element works. Now, within the documentation you have various operators that you can make use of. So there are various examples which are available.

So here we are making use of a condition where the user agent is not equal to certain specific user agent. I still remember that in one of the organizations they used to have a condition similar to this. Now, what they used to do was they used to run TerraForm. So they used to do something where the user agent is not equal to TerraForm. Do not allow him to modify the changes something similar to that. So there are a lot of examples that you can create with the help of the condition element. Now I will really encourage you to go through the documentation in order to understand more in detail about how condition element works and also various condition operators.

18. AWS Security Token Service

Hey everyone and welcome to the Knowledge Portal video series. So today what I decided to do is I decided to wake at around 554. I actually work at 330 in the morning and the first lecture that we are recording for the day is at 555. Just to make sure that you do not listen to the cooking sound of our neighbors, but it seems that our neighbors are also awoke quite early. So before they start to cook and you hear noise, let’s go ahead and complete our lectures. So today’s topic is AWS sts. Now, this is a pretty interesting topic as far as the IAM is concerned. So let’s go ahead and revise few things before we touch the topic of Sts. Now, we have already been discussing related to how an Im role work in the previous lecture.

So let’s revise. We have a EC two instance over here and we have a S three bucket. So you can consider this as AWS resource. Now, EC to instance wants to connect to a specific AWS resource which is S three bucket. So there are two ways in which we can do it. The first way is we put the AWS access and secret key with the help of AWS configure command. And the second is we attach Im role to the EC to instance. And then we will be able to access the bucket depending upon the policy. So we will focus on the second option which is the IAM role where we create an Im role and we attach two policies to that Im role which is S three read only and EC two read only.

Once we create the policies for the Im role, we attach the Im role to the instance and then instance will be able to view the bucket. So let’s do one thing, let’s try this out first and then we will go ahead in much more depth. So I have my EC two instance running which is Kplabs two B and there is an Im role called SKP Labs. So if I just go to IAM, I’ll click on roles and I’ll select Kplabs over here. So there is one policy which is attached which is Amazon s three readonly access. Now, since this Im role is connected to the EC two instance, the EC two instance will be able to inherit the policies which are part of the Im role. So let me quickly log into the server and if you remember the EC to instance metadata.

So first let’s do AWS s three LS. So I am able to view the instance. This is because of the policy which is attached to the in role which was S three read only. Now, if you remember about the EC to instance metadata so I’m doing a curl on the security credentials related to the KP Lab Im role. It gives me three things. It gives me the access key, it gives me the secret key and it gives me the session token. Note that these three things have an expiration. So after the expiry, all of these will be removed or it will be automatically deleted or it will become invalid. Now, you can actually use these three things in your laptop. It is not really necessary that it needs to be connected with a role. You can use these three things in a desktop computer, and you will be able to do it as S three LS as well.

We’ll be looking into how that would really work. But one important thing to remember is that let’s go back to our PPT. One important thing to remember is that the access key, secret key, and the token that we received in the EC to instance, via the EC to instance metadata, it is not given by the Im role. It is actually given by a service called Sts. And that Sts service is responsible for providing you those credentials. So the Im role has a trust relationship with the Sts service, and through the Sts service, you receive those credentials. So let me show you. So if you look into the Im role, there is a Trust relationship option over here. And if you click on Edit Trust Relationship, this is the policy. So in the policy, as far as principle is concerned, you see EC two amazonaws. com.

So this is the service. And this service will be able to access the Sts assume role. Now, the Sts service will be able to generate those credentials. And if we really remove this, then we will not be able to generate those access secret keys. And that AWS s three LS command will not work. Okay? So let me just do a cancel over here. So I hope you now got that it is the Sts which generates the credentials that you see over here. And Im role does not really have to do directly anything with the generation related aspect. You can just access the credentials through an instance metadata which is generated by Sts. Perfect. So, going back to the third slide. So the temporary security credentials are the ones that we just looked via the instance metadata. So just to revise AWS, Sts allows us to create temporary security credentials.

Now, there are a few important things to remember as far as the temporary security credentials are concerned, is that they are short term and they expire after certain duration. This is very important to remember. So they keep on rotating, and the older credentials will be invalid after the newer ones are generated and the expiration is over. Now, since they have limited lifetime, the key rotation is no longer explicitly needed. Now, the key rotation was one of the challenging part. Specifically, when we generate permanent access and secret key, we have to rotate it at a specific interval of time. Let’s assume 90 days, so that even if they are leaked over the public, they will be invalid after a certain duration of time. So this is where the temporary security credential comes into the picture. And this is one of the screenshots related to how we can generate a temporary security credentials.

19. AWS STS – Migrating the EC2 Role Credentials – Part 2

Hey everyone, and welcome back. Now, in the last lecture, we had generated the credentials, or we had received the credentials through the instance metadata. We discussed that we can actually use this credentials outside of EC Two in our laptop as well. So let’s go ahead and understand on how it really works. So, what I’ll do is I’ll copy these three important parameters, which is access key, secret key and the session token. Let me just copy this and I have my virtual machine running over here. I’ll just log into the virtual machine. Okay, perfect. So let me do one thing. Let me open up the G edit and I’ll paste it to wire. Perfect. So the first thing we’ll do is we’ll go to the AWS credentials file and I have my credentials configured for Alice user that we had done earlier.

So I’ll come into south and just to verify, if I just do AWS S three LS, it will not work. Okay? So let’s go ahead and configure these credentials which were generated through Sts via Im Role in an EC Two instance. So let’s do that in our local credentials file. So let’s name this EC two role. I’ll put AWS access underscore key underscore ID is equal to I’ll put AWS secret underscore access underscore key and within the access key ID, I copy this out within the secret key. Let me copy this. And there is one more field, if you’ll see, which is the token. So I have created a format, the format which is used to declare the session token. I’ve written it down here so that I don’t really make any mistake. So I’ll copy the token and I’ll paste it over here. Perfect. So now we have copied the three things.

If I do AWS S three LS now, and I’ll put a profile of EC Two role, now you will see I am able to get the same permission which a role has. Now, a few important things to remember. And let’s assume a user has stolen this credentials. He has a login to the AWS server and he has stolen this credentials. Now, good part, since these credentials are generated by AWS, these can be expired. So this will expire after certain duration of time. So even if someone has stolen these credentials, you don’t really have to worry too much because they will be expiring eventually. And the expiration time is also mentioned when you generate an instance metadata. So this is it about this lecture. I hope you got the basic understanding on how the tokens are generated and we can use these in different instances as well. So, this is it about this lecture. I hope you liked it and I look forward to seeing you in the next lecture.