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

20. AWS STS – Architecturing IAM user keys the right way – Part 3

Hey everyone and welcome back to the Knowledge Portal video series. Now, in the past few lectures we have been discussing more about the AWS Sts service and today we will look into how we can implement the Sts service for the user management. So let’s go ahead and understand on what I mean here with the use case. So the use case is, Matthew is a developer and he’s testing his code on the local environment in his laptop. Since his code requires access to AWS S three, he needs access and secret key. Since there is no Im role that can be used here, what is the best solution to implement? So, very simple use case and this is something that you will find in most of the organization. So developer wants to test their code in their local laptops.

Since there is no Im role, you cannot really generate or you cannot attach Im role to the EC two instance and ask developer to test their code in the EC two. So in this case, there are three ways in which we can approach this specific solution. First is provide him the access and secret key and tell him not to share with others. This is one way. However, they will definitely share with others. This is one thing that I’ve realized. Second thing is provide him with the keys but ensure the key rotation happens every 90 days. So this is the second way. Now, the problem here is let’s assume that we have given him the access and secret keys and the keys got leaked somewhere on the internet. So till that 90 days, which is a pretty high period, the keys will remain leaked.

And trust me, if you rotate the keys less than 90 days and it becomes quite hectic task. Specifically if you’re working in an organization where there are 300 400 developers. So this is not a very ideal solution. The third solution is allow users to use Sts to generate the temporary credentials and this is the best way, trust me, this is the best way to do it. And if you are a solutions architect in an organization and developer is asking for keys, this is the solution that you must implement and you will be regarded as a good security engineer by a lot of people if you implement this way. So let’s go ahead and understand on how we can do this because in the last lecture we actually stole the credentials from the EC to instance and we put it in the virtual machine. So that is not an ideal way to do it.

So let’s look into the most ideal way to achieve that. So the first way is that we create a cross account role in IAM. This is the first thing. Second thing is we attach a read only policy to that I am role. That is the second part. Third part is we allow the user to assume this specific role with sts. And the fourth is remove all the policy from the user except assumed role. So I’m definitely sure this is something which is confusing. So let’s go in and implement and it will become much more clear. So what I have is I have my Alice user over here and the user has specific policies which are attached. Let’s remove all of those policies. Let me remove the first one and let’s remove the second one and let’s remove the third one as well. Perfect. So now the Alice user does not really have any policy, just the policy to change the password.

So if I go inside the virtual machine so this was the part of the last lecture that we already discussed. Let’s do one thing inside the AWS credentials. I’ll comment out the things that we had done in the last lecture and the access key which is present here under the default belongs to the Alice user. Notice the Kuq. So we’ll just verify it again. So if I do an AWS s three LS, now you see the access is denied. The reason why access is denied is because now we have removed the S three policy from the Alice user. We just verified access key Kuq. Perfect. So this is the Alice’s access and secret key in the virtual machine. Now, if you see over here, the first step is create a cross account role in Il.

So let’s go ahead and do that. I’ll click on roles, I’ll click on create role and there are four options over here. Earlier we used to select the role for easy to instance but this is something that we don’t want. So we’ll select another AWS account. So this is cross account. So it is asking you for the account ID. Let me get the account ID from the support center. I’ll copy this, I’ll paste this out. Perfect. I’ll click on next. Now I’ll put S three read only policy. I’ll click next. I have to give a role name. Let’s give Sts role description. This role will allow user to generate temporary credentials. Perfect. And I’ll click on create role. So now we have the role created.

So if I just click on the role we have one policy which is attached and in the trust relationship what the principal is? The principal is any user within the AWS account with the account ID which we have mentioned will be able to do a SPS assume role. So this is something very similar to the EC two role that we had seen where the principal was EC two Amazon Aws. com. But instead now we have the account ID or the ARN of the account. So I’ll just click on cancel. So this is the first step. We did the second step. We attach the st read only third step allow user to assume role with Sts. So now what we want to do is we want user Alice to assume this role or user Alice should be able to connect with this specific role like how easy to instance connects with the EC two role.

Similarly, a user should be able to connect with the role that we had created and this is definitely possible. So let’s do one thing I’ll go to the Alice and in order for Alice to assume the role I need to create a policy. I’ll go to generator and here I need to select the Sts Amazon. So this is something which I find really hard to find the right service in time. So we have Sts security token service in the actions I’ll allow, assume role and note the ARN. So here we have to put the ARN of the role which the user can assume. So let me go to the IAM again I’ll go to the roles and the role that we had created over here I’ll take the ARN of the role and I’ll paste it over here and I click on add statement here I’ll say assume role perfect. So now we have two policies.

The first policy will allow the user Alice to assume this specific role. The role name is sts role and the second policy which is on the role side says that any user within the account this account will be able to assume or connect with this specific role. So policies has to be on both the sites. Remember that perfect. So now what we can do is we have to in the AWS CLI this is the last step we have to run this specific command which will generate a token for us. So let’s see what is the command. So I’ll just write it down in my Atom editor which is AWS stoom role. Let’s go back. So AWS sts assume hyphen role and there are a few important parameters I’ll copy all of them. Let’s paste this out. I’ll put assume hyphen role and the parameters is the role ARN and the role session name.

So the role ARN would be the ARN of the role which got created I’ll copy this out and I’ll paste it and the role session name would be the temporary session name that will be created and I’ll just put KP Labs as a session name. So what this will do is once the user runs this once the Alice user runs this user Alice will be able to generate a temporary token. So I’ll copy this in my virtual machine. So the only permission, I hope you remember the only permission the user Alice has there is only permission that user Alice has is to assume the rule and nothing else. There is no S three read only permission, nothing is there, just the permission to assume the rule. So now let’s go to my virtual machine and I’ll paste the command.

Let’s see some formatting issues and there was one more part let me just I think it did not get copied. Let’s write that out again. Okay, so the second line is not getting copied. Let me just reformat it again. And I’ll just specifically copy the second line. Perfect. So it seems to be proper. Now, let me just make it big so that becomes clear. So let’s try this out. And now, you see, I am able to generate the access key. This is the access key. This is the secret key. And this is the session token. And if you will see over here, the session name is KP Lapse. And the same will be reflected in the ARN. Which is the ARN? The role name? Kplab. So this is the temporary session name that is created.

And now if you see if I do an AWS s three Alice, it will not be allowed because the only permission associated with the user Alice is to assume a role. That is the only permission. So the user, Alice must run this command. She must obtain the access key, secret key and the session token. And from this, she should be able to do an AWS s three LS. So let’s quickly go to AWS. Credentials. Okay, I’ll go to AWS. Credentials. I’ll create a new credentials. Sts. The AWS access key ID is equal to AWS secret access key is equal to An AWS session token is equal to perfect. So let’s format it in a good way so it becomes much more cleaner. Perfect. So first thing we’ll use is we’ll copy the access key ID. I’ll copy it here. The second thing is we’ll use the secret key. I’ll copy the secret key.

And the third thing is I’ll take the token, the session token, which is associated with the KP lab session, and I’ll paste it and I’ll save the credentials. Now, if I do AWS sreels we have to specify the profile, which is Alice sts. And now, you see, I am able to view the buckets. So this is the right way of doing things. Now we can even specify if you go to the documentation, we can even specify the expiration timer with the hyphen hyphen duration seconds. So this is something that we can do. One important thing to remember that the credentials which are generated or which we generated the credentials which we generated these credentials, they are valid only for 1 hour. Okay? So very important thing to remember. This value can range from 900 seconds, 15 minutes to 1 hour.

So minimum is 15 minutes, maximum is one R. And after 1 hour, this credentials will be invaluable. So this is the right way of doing things. Do not give a permanent access and secret key attached with a policy. If the Developer Wants the Access and Secret Key, give it to him or her with the assumed rule based Approach. So this is the right way of doing things. And if you do It This Way, sure that if you are going through an Audit, the Auditor will be really happy and give you a good score. So this is it, about this lecture. I hope you understood more about the staff service, and I look forward to seeing you in the next lecture.

21. AWS STS – Automate the temporary credentials – Part 4

Hey everyone and welcome to the Knowledge Portal video series. Now, hopefully this will be the last lecture for Sts. I hope you’re not bored. So one question that might arise is that many of you might have this question. Like whenever we generated a temporary credentials, we had to manually copy the access key, we had to manually copy the secret key and we had to manually will copy the session token inside the AWS credentials file. And since these are valid only for 1 hour, developer will have to run this command every 1 hour and he’ll have to copy and paste these credentials manually every 1 hour. So this is really not a very idle way to do it and developer will not follow this if you give this specific approach. So there is a workaround in which we can automate this specific process.

So how we can do this is, this is a very simple way of doing this, one of the most easiest way. Let me show you. So I have created a new profile where there are two parameters which are needed. One is the role ARN and second is the source profile. So the role ARN here will be the one which we generally run in the Sts assume role. So you see, when we run this specific command, we give the role ARN. So this is the role ARN that we need to give. So I’ll copy this, I’ll go to AWS credentials and the role ARN I have to supply the ARN of the role that needs to be assumed and in the source profile I have to give the name of the source profile which is default. And now whenever I want to run, I have to do AWS CLS with the profile automated.Okay, ARN is invalid. Let’s just quickly verify oops, I think we made a small mistake.

There is a colon over here. Let me paste this and let’s do it again. And now you see I am able to view the s three buckets. So what really happened is in the profile we called the automate profile, so we called this specific profile. What this profile will do profile has the role arrange and profile will use the credentials, the access key, secret key of the default profile. So first thing will happen is it will take the access and secret key associated with the profile name that we have mentioned here, which is default. So it takes the access key, it takes the secret key and it takes the row layer in and then it will run the command something similar to what we had done. It will run a command something very similar to this.

It will generate the temporary access key, secret key and the token and it will allow the user to view the contents without having to manually put the access key, secret key and token in the credentials file. So this is an automated way of doing things. Once you do this way the only thing that you have to tell the user is to run the command with profile automate and everything will be working as expected. So after 1 hour, once the credentials expire you don’t really have to regenerate the credentials manually and put it inside the credentials file. So this is the automated way of doing things and this is something which I would really encourage you that if you are a solutions architect then you should be implementing this kind of approach or something very similar. So this is it about this lecture I hope this has been informative for you.

22. Understanding Federation – Part 01

Hi everyone and welcome back to the Knowledge Portal video series. So, in the previous lecture we spoke about delegation and how a user from one account can do a zoom role to the second AWS account. So that is what delegation was all about. Today we look into very similar concept calls federation. Again, this is a very, very important, important concept. And federation is generally used in most of the enterprises based companies. So let’s understand what federation is with a very simple use case. So let’s assume that there are 500 users within an organization and your organization are using three services. So when you have Jenkins, jenkins is generally used for CI CD. Second is AWS, and the third is HR management system.

Now, as a solutions architect and a system administrator, you have been assigned a role to give users access to all of these three services. So now the question is there are 500 users and you need to give access for the 500 users to all of these three services. So how will you go ahead and approach this particular use case? Now, one very simple way of doing is you add 500 users, first in Jenkins, then you add 500 users in AWS via IAM, and then you add 500 users in HR Management system. So this is one way. Now, the problem with this kind of approach is that let’s assume that tomorrow ten more users join in. So what you have to do is you have to add ten users here in Jenkins, then AWS, and then in HR Management, which is very clumsy, it takes a lot of time and it is not an idle way of doing this.

So this is again a hard work. And for lazy people out there like me, this is not a very ideal approach. So what we can do over here is we can have a central directory. So here we have a LDAP. In LDAP all the users will be stored. So administrator has to store the user only in LDAP. Once the users are stored in LDAP, depending upon what are the filtered ted settings that you have done, user will be able to log into Jenkins, AWS and HR Management System directly. So no need to create user in Jenkins or AWS or HR Management system, just create a user in LDAP, establish a trust relationship between LDAP and all three services, and then user will be able to seamlessly connect to all of these three services. And if you see, it becomes very simple.So now let’s say that tomorrow ten users come to your organization.

All you have to do is you have to add all those users in the LDAP directory and it will do the job for you. So this is a very simple way and most efficient way of doing this because generally, if you look into a critical organization, like an organization who are following PCI DSS standards, you need to immediately revoke the access once they leave the organization, like once they are either resigned or terminated. So again, going to each and every service and disabling the account will take time. Instead of that, if you are using LDAP, all you have to do is just disable the user in the LDAP and that user will not be able to log in anywhere. So again, very simple and efficient for using and this is one of the reasons why most of the enterprises they use LDAP or something similar.

So there are various solutions which can be used for storing central users like Microsoft Active Directory is something which is very famous in most of the organization. And as far as Linux is concerned you have Red Hat Identity Management or free IPA which does the similar things. So let me do one thing, let me actually show you the demo of free IPA on how exactly it looks like. So I am logged in over here, this is a free IPA and if you see there are a lot of users which are present over here. So if you go to the different screen, let me actually I think it got logged out. Let me log in once. So generally all you have to do is you have to store the user in this identity store and then you do a federation from year to your AWS. So we have a lot of users which are present over here.

You can do something like within the user group you can create a user group call as production. So this is very similar to what we did in the delegation. So let’s create a user group called as production. And once you create a user group production, you add the users within this particular group. So let me just add some random users LDAP user five, LDAP user nine and manager. I’ll add over here. Okay, so these are the three users which are created now in the AWS site you can create a role which does the federation and you can establish a trust relationship like only the users which are present within the production group can log in to the production role which is present within your AWS account. So this is one of the basic on how you can go ahead with federation.