Practice Exams:

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

  1. IAM Policies – Part 02

Hey everyone and welcome back to the Knowledge Portal video series. Now, we already discussed about the basics on what I am policy consists of. Today what we will be doing is we will take a sample use case and we will be developing our own IAM policy to achieve the solution for the specific use case. So let’s go ahead and understand the use case. So the use case is alice has been given one EC two instance for testing. As the part of the access she must be allowed to start and stop her EC two instance. It also mentions the instance ID and the region in which the EC two instance consists of. Now, this is a very generic use case which you will find most in every organization where a developer has been given a dev instance and since he has access to the dev instance, they would ideally want the access to start and stop the instance whenever they want.

And let’s look into how we can achieve this specific use case with the help of IAM policy. So I’ll go back to my item and this is one of the sample policy which we had studied in the previous lecture. We will be modifying this specific policy to achieve the use case. Now, since if you look into the use case over here, the access if you see she must be allowed. So we are not denying anything, she must be allowed. So the effect will be allowed and what should be allowed? She should be allowed to start and stop her EC two instances and the instance ID is present over here. So the first statement over here, the effect must be allowed. Now, what must be allowed is a question. So she should be allowed to start instances. So EC two start instances.

Now, again, since we are having multiple statements over here, remember we had already discussed that whenever we are having multiple statements it should be under the array. So I’ll start with an array and it must be enclosed within the array. So to make it much more cleaner, I’ll just put it in this way and since there is one more statement which is present below this I have to put a comma perfect. So this looks much more cleaner. Let me just perfect. So now what we have, we have effect as allow what needs to be allowed and the condition is easy to describe should be allowed, easy to start instances should be allowed and easy to stop instances should be allowed and on what resource that basically means on what EC two instance.

So if we just paste this policy what the user will be able to do is since resources asterisk user will be able to start and stop any instances in any region and this is something that we do not really want. And that is why there is an explicit instance ID which is present over here as well as the region name. Now there is a specific format which we already discussed which is called as the Amazon Resource name. So in here we have to specify the Amazon resource name. So the way that I do is say we need I’ll just say Amazon Resource name. Let me open this up and here if you’ll see it will basically show you the ARN or the Amazon Resource name format for each of the services in AWS. Currently we are more interested in EC two so I’ll select the EC two over here and under the EC two also there are a lot of things which are present like VPC, VPN, ID, et cetera.

We are not interested in all of these, we are specifically interested in the instances related part. So let’s find where the instance part is. Perfect. So this is the instance part. So this is the easy to instance part. I’ll copy this format and I’ll paste it over here. Perfect. So now we have to edit this specific format. Now this will remain same region. The region which was mentioned was Oregon. So if you remember the region name, I am already in Oregon and it will see over here in the URL it is US West Two and this is one of the easiest way. So if you go to North Virginia the region name in the URL changes. So this is one of the easy way to identify what is the region name. So I’ll put the region as us. West Two. Next comes is the account ID.

So I have to put the account ID. So let me go to support support center and I am taking the account ID from here and I’ll paste it in this field. Perfect. Next field is the instance instance ID. So here we have to specify the instance ID which we can get from the use case which is mentioned over here. So this is the instance ID and I’ll paste it over here. So now we have a perfect Im policy which is ready. So the Im policies allows to do this operation which is described Start and Stop instances and it is allowing on what it is allowing on this specific resource. Perfect. So let’s do one thing. Let me go to the Alice user and before we actually apply this policy, let’s verify if she has access to the Start and Stop instances.

So I’ll try and start this specific instance which is my first instance as a name and now you see it is giving me an error which basically means that you are not authorized to perform this operation. Perfect. Now let’s go ahead and copy our policy and go to the Im console. We’ll go to the users Alice and let me remove the readonly policy that we had defined earlier. I removed this one so there are no policies right now. So if you just go to the EC to Dashboard and click on Refresh. Let me just try and open this up so you are able to see the instances. So this generally happens sometimes. So in this case, if you get this error, wait for a minute and the reflected policy will be reflected to the individual user.

So sometimes it might happen that the developer will come and he’ll say that you are still getting this error even though you have defined him a read only policy. In such cases, ask him to wait for a minute or two and if that also does not work, ask him to sign out and sign in once. So few important things to remember when you are working as a solutions architect. Perfect. So now I’ll add an inline policy. I’ll put a custom policy over here. Let me paste this. First thing that you should do once you write a policy is validate the policy. Just put EC to start, stop and validate the policy. Okay. So the policy is valid. I’ll click on Apply policy and the policy is applied. Perfect. So now what we can do is we can go to the Alice user console. I’ll click on refresh.

Let me go to the instances. Okay, so it is saying you are not authorized to perform this operation. Now, the reason why it is saying this specific message is because in order to see the specific details related to instances, you need to have an easy to read only access because there are a lot of other things which are present over here. So let me quickly do one thing. I’ll click on add permission. I’ll attach a policy which basically says EC to read only. I’ll give him a read only access. Perfect. And now if I just refresh the console once, let’s just do it. Perfect. So now I am able to view all the instances. Now let me go ahead and let me start this specific instance. So this is the instance ID which we had mentioned within the IAM policy. Let me go ahead and start.

Let’s just refresh. Okay, so it is starting. So basically we are allowed to start. So the user Alice is allowed to start and we can also stop the EC two instance. So now you see the EC two instance is getting stopped. So this is the basic about writing IAM policy. I hope you got much more clear understanding on how exactly the IAM policies are written. Now again, we will be going more in depth in the upcoming lectures, but I will really encourage you to practice this once so that you can gain much more better idea on how things work in IAM policies. So this is it about this lecture. I hope this has been informative for you and I look forward to seeing you in the next lecture.

  1. Delegation – Cross Account Trust – Part 1

Hey everyone and welcome back. In today’s video we’ll be discussing about the identity account architecture in detail. We will also have a small demo so that it becomes better understood. Now typically small organization, they begin their journey with a single AWS account. Now if you just have a single AWS account the management becomes much more simpler. So let’s say a developer wants access to this account. So you can go ahead and create an IAM user and password and you can go ahead and create an access and secret key if required. And if the developer is leaving the organization you can go ahead and disable the username and password and deactivate the access and secret key.

So this part of management is pretty simple. However, when the organization becomes big, the part of identity becomes quite challenging. So now what we have is we have multiple AWS accounts. Now let’s assume that you have five AWS accounts and there is a developer who needs access to each one of them. Now in a simplistic very basic approach, what you will do, you create the username and password of the developer in account one, then you create an account two, then in three, then in four and then in five. Similarly you’ll create access and secret key of the developer in 1234 and five. Now the developer is leaving the organization again, you’ll have to log into all the five accounts, you have to deactivate the access and secret key, you have to disable the user.

Now this is not a very ideal approach because typically when an organization becomes big they will have hundreds of employees and you do not really want to add the employees details in each and every database account individually. So in order to solve the problem, you have the architecture of identity account. So what happens in identity account is you have a single dedicated AWS account. In this we refer it as an identity account and you create the username and password in this specific account. So you create a username and password and you create an accident secret key in a single account. Now you establish the trust relationship between multiple AWS accounts that you have within your organization with this identity account.

So now what will happen is the developer, all he has to do, he has to log into the identity account and from here he’ll be able to switch and log in to various other AWS accounts depending on the permission sets that he has. Now if a new person joins your organization, all you have to do is you have to add him to this identity account. If he leaves the organization you have to remove from this identity account and if he forgets the password, all you have to do is you have to reset his password from this single A device account. So the management becomes much much more simpler in this type of architecture.

So for our demo purposes, what we’ll be having is we’ll be having two accounts. One will be the identity account and second would be the production account. And we’ll be creating the user in the identity account and will not be creating his user in the production account. However, we’ll look into how exactly he’ll be able to log in to the production account even without his Im user being created here. So this type of architecture requires three steps of implementation. First is create a user in account A. So this account A is basically the identity account. Second is create the cross account role in account B. And third is allow users to switch to account B role. Now, we’ll be looking into each of these steps in the next video of the practical session.

However, in today’s video, I’ll quickly give you a demo on how exactly it might look like. So this is the account A will refer this account as the identity account. Now, if you see this account ID starts with 0377 and it ends with 10 eight. Now let me log into this account with im user that I have created. All right, so I have logged into the identity account. Now, one thing that you should remember is that if you have a dedicated identity account, make sure that users do not really have any permission over the services. So if I quickly open up the EC two year, you see it is giving not authorized and this is the recommended way make sure you do not really give permission other than switch roles. That we’ll be looking into the next video into the identity AWS account.

Now for the demo session, this is the identity account where the user calls yosh has logged in from. Now he wants to log into a production account. So this is the account that he needs to log in. So in order to do that, he needs to have a sign in link. So the sign in link looks something similar to this. Now, if you look into the sign in link, let me actually press Enter. So this is the sign in link for the production account which is the account B. Now, if you look here, the account number is little different. It starts with phi A five and the role is called A Cafe and KP Labs. Now, we can call it production Account. Here you can put it as a display name and you can click on switch role.

So once you click on switch role, what will happen is the user will log in to the production account so he’ll be able to switch the cross account role that was created wire. So this is the production account. Now this is the account where you can give the user appropriate permission. So let’s say that this Yash user wants to have access over S three, then you can give access to the S three console to the Yurch user. So currently there are no buckets. So this is how it will look but the S Three access has been granted. So currently I am logged in as an administrator user in the new account which the Ush has logged in. If you see this account has a sign in link of phi eight five.

Now, within here I have a role which is created and this role is called a cababs and this role has the Amazon S Three read only access and the US user has basically assumed this specific role and he has inherited all the permissions which is associated with this role. And since this role has a S Three read only access is yosh will be able to perform the read only operations in S Three. So this is the high level overview in terms of demo for the architecture of identity. In the next video we’ll start from scratch and we’ll look into how exactly we can go ahead and create the cross account roll for the Identity.