How to assume a role with AWS Security Token Service (STS)

I'm in my new machine there's another method to provide credentials to the PowerShell or command line using secure token service or STS you can provide temporary credentials that is valid for a short while so that you are not running into the risk of having long term secret key and access keys so I'm in my development machine if I open PowerShell and then type get s3 bucket it's going to give me the list of buckets and the permission for that one came from the instance profile so if I go into my ec2 instance which is I'm running a new machine and if I select the I am roll develops new machine and then open in new tab the permission for that came through this Amazon s3 full axis so for a moment let's remove these to make sure that this instance doesn't have Amazon s3 relaxants and I'm going into the PowerShell again and then type get s3 bucket so now you don't have access so let's set up the environment in a way that I take the credentials when I want it using secure token service so let's first create a user to do this lab if you go into the I am section of your AWS console let's create a user let's say like before my test user for the programmatic access next permission but here I'm not giving any permission for this user so let's click Add next review create the user so I create the user and I got the access key ID and the secret key so let's save this in my baby so this is my access key and the secret key is this so if I try to provide this access key and the secret key of course it's going to throw an error so let's say for example get s3 bucket and then if I provide access key with this access key and the secret key has this secret key if you know of course give an error because this user does not have s3 access that's fine so what I'm going to do now is grant this user permission to assume a role in AWS so how can we do that so if you go into your I am section so let's close this if you go into your I am section of the screen under Rawls we can create a new role so let's create a new role in this case let's call it it's the service that I'm going to trust a cc - of course you are going to change it shortly to trust the user and then I'm going to add permission the permission I'm going to add is a manage permission which is in this case s3 full access click Next click scribble and let's call it to my test crawl so this is the role that I define so create the role when you create the role you can find that this role my test role trust easy to to assume itself so let's go into this role and for the trust relationships instead of trusting the easy to let's trust a user for this so what I'm going to trust here is the principal is the service instead of service let's trust a user so how can we do that so the user that I created if you go into your I am you section let's open it in a new tab the user that I created is this user my test user the AR n is disorder Amazon resource name so let's copy this AR in and then if I go into this section where I edit the trust instead of service I'm going to trust AWS user which is this user the account ID you can also trust not only the use of this account you can trust a use of another customers account another one of your partner's account so in this case I'm going to trust this user and update the trust policy so this user now can assume this role and this role has the permission of s3 full access so let's see how we can use this special wiring to assume the role from that user and then provide access to s3 because I don't want to provide the credentials again and again with for the user let's set the AWS credentials for this session access key is and the secret key is this one so I said the session access key and secret key so if I can't forget s3 bucket still it's not going to work s3 buckets still it's going to give access denied because this access key and secret key does not have access to execute this s3 bucket because we did not attach any permissions for the user but instead of that what we can do is we can use SDS get credentials and for example you can say use SDS roll roll a RN is the name of the roll Aaron so I got this roll a RN from the role that I created so if you go into your I am section and if you go into your roles the role we just created is called my tester on the role a RN is this so this is the role that I'm going to assume so I copied it and that role has a Mersenne is three full axis and it trusts this user to assume that role so I copied this role Yaron so if you go into the roles this is the role I created so this is the role in RN and that's the role owner and I have provided here as the Aaron of the road so I say use SDS role and I take the credentials of that so you can find I give it the role session name as some kind of name and then I give the credentials so I get the credentials now now these credentials that I got from this partial object has an access key and also it has a secret key this access key and this secret key came through the assumed role and in trustingly that has the permission to access the s3 bucket for example if I take gate s3 bucket and if I type it like this it's going to course give an error but if I type get s3 bucket but then provide the credentials that I got through assumed permission or STS role which is the credit object you can find that it will successfully get the access to s3 now this credential object is very interesting so examples or what we try P reverse this is the command we type use STS wrong and we got the credentials and if you look at the credentials access key is this one and then the secret green is this one if I type it again then this access key is is different so what you get is some temporary credentials you can find that that's the key and secret key you can find that the access key and the secret key God are actually different because it's actually a temporary credentials that you are getting you can find the expiration time of this credential so these credentials will expire because it's a temporary one on this time if you look at the documentation for us STS Hall one of the parameter is duration in seconds so let's try to give that duration in second so in this case I'm going to say clear the screen for use STS Hall for all they are and this is the role that I am going to pass you I gave it all such a name like my session name but in this case I'm going to give duration in second so let's give 30 seconds as a duration all right and then type in so must have value greater than or equal to 900 so the minimum time that it can have is 900 so let's give about 900 seconds so that's good and then I use gate s3 bucket and for the credentials I'm going to provides the credentials I got here so now I can access these gate s3 bucket with these credentials until this expiration happens 900 seconds that's about 15 minutes so you can have these critic credentials for 15 minutes so if you try to use these credentials after 15 minutes it will be already expired and you will not get access so that's a much better secure way to access these services than having a fixed access key and secret keys about 15 minutes has already passed so let's try to use the same access key the credit to access s3 bucket credentials I'm going to pass the credentials let's see what will happen so you can find that the provided token has expired because I spent about 900 second after this command and the token has already expired so I need to renew the token to access this again so I can of course a type cred get the new credentials again and then type get a three bucket with credentials the credit which I have only freshed so now you can access again well this become Handy's when you have multiple environments imagine that you have three environments called production environment pre-production environment and development environment what you can do here is you can define three different roles instead of three different users or three different ec2 instance or three of three different ec2 instance profile you can define role one two three for example role one will provide just enough permission to deploy into production and role 3 will provide just enough permission to deploy into development environment but you can then do is define a principle and then let these roles trust that principle so the principle can be a user ec2 instance may be an AWS service it can even be a double base account that one of your partner or customer owns so this user or the principal does not necessarily need to be something that you own in your account it could be another it of this account another user from your partner another custom account so once these roles trust this principle the principle can assume the role for example if it is going to deploy into production environment it can assume the production environment role one and then make the necessary modifications to the production environment when it wants to deploy into pre-production it will assume the pre production role and then deploy into production environment same for the deployment if you want to deploy something or make modification to the development environment you assume that role and then push those changes into the development environment so in this way you can have a single principle and multiple roles corresponding different and then switch between the roles to assume the certain permissions that is just enough to make modification to that environment it's more secure and less error-prone

Channel: cloudopian

Views: 25,138

Keywords: Azure DevOps, PowerShell, AWS, STS, Secure Token Service, Assume Role

Id: dqF4VJCska4

Length: 15min 7sec (907 seconds)

Published: Sat Jan 11 2020