(upbeat music)
- Hi, I'm Wayne, a Cloud Support Engineer
here at the AWS office in Sydney.
Today I'm going to show you how to assume
an IAM role using the AWS CLI.
So, let me walk you through the process.
In this video I will create a new IAM user
and a new IAM role in the same AWS account
using the AWS CLI.
This step should be performed by the administrator,
who has the permission to manage
IAM users, roles, and policies.
Once you open a terminal window,
you will need to create an IAM user,
which will be used to assume the role we create later on.
We are now creating a new IAM user
called "test user" with this command.
Note, the user ARN from the Output SN
will be deleted later.
Then we will create and IAM policy
to grant the test user with only access
to ec2 instances and permissions to assume an IAM role.
Here I am using vim, but you can create
this policy file using any preferred task editor.
Inside the policy here is the contents
we are adding
in which "ec2:Describe*"
will grant the ec2 read-only access.
"Iam:ListRoles" will allow user to find
a target IAM role in the account
if the full role ARN is not known.
Lastly, the "sts:AssumeRole" will allow the user
to assume the target IAM role.
Now, I'm going to use the wq to save the file.
Using the following AWS CLI command,
we will create this policy
as a customer-managed policy in the AWS account
so that it will be available for use.
Next, we will attach the managed IAM policy
to the user and replace the account number
field that's marked out with your own account ID.
Let's verify that the policy
is successfully attached to the user.
Now, let's create and access key pair
for the test user and copy the output to a notepad
to be used in later steps.
Now, I'm go ahead and copied AccessKeyId
and SecretAccessKey.
We've created IAM role that can be assumed by the test user.
This role has read-only access to RDS.
This step should also be performed
by the administrator who has the permission
to manage IAM users, roles, and policies.
Again, I am using vim editor to create
a trust relationship policy of the IAM role.
Inside a trust relationship policy
we have principal as the root.
This will allow all IAM entity of the account
to assume this role as long as they have IAM permissions
for the sts:AssumeRole API.
In present days with the actual user on
can restrict the role to be assumed
by a nominated IAM users or roles only.
Now, we going to save the file with the same wq.
Let's go and create a role with this Trust Policy.
Make notes of the role ARN for use later.
Then we will attach the AWS managed policy called
AmazonRDSReadOnlyAccess
to this row with this command.
And we can use this command to verify that the policy
has been successfully attached to the role.
Now, we have the IAM user and the IAM role ready.
So, we can then configure the AWS CLI
for the test user and verify its permission.
I will be doing this on a different ec2 instance
where AWS CLI has not been configured yet
using this command: "aws configure"
to configure the test user
as the default profile in AWS CLI.
Alternatively, you can also use aws configure
with a dash-dash profile with a named profile
to use the named profile feature.
Now, once you hit Enter you can see
it's asking for the access key and secret key
that we had saved earlier.
Now I have pasted my access key pairs
and have set my region to ap-southeast-2,
which is the Sydney region.
Then we can verify that the subsequent CLI commands
are being invoked as the test user
by running this command.
And output should contain a user ARN,
which looks similar to this.
Then we can confirm that the IAM user
has only read access to the ec2 instances
by running this command.
And we will also confirm that the IAM user
has no access to RDS DB instances
by running the command here.
Finally, here are the steps
to assume an IAM role using the AWS CLI.
We will run the assume-role CLI command
to assume the role ARN from the previous steps,
achieving a set of temporary credentials.
You must provide a session name.
Here I used AWSCLI-Session as an example.
If you have forgotten the ARN of the test role
you can find it again using the AWS CLI command.
If both of the conditions below are met,
then the assume-role API call will be successful.
First, the API caller, test-user,
should have the permission of "sts:AssumeRole"
to the target role.
Exception will be the target is in the same account
and the Trust Policy has explicitly listed out
the full ARN of the API caller.
Second, the API caller or its root
is on the trust relationship policy of the target role.
The output from the AssumedRole API
should contain AccessKeyId, SecretAccessKey,
and SessionToken.
Note the time stamp of the Expiration field
is in UTC time zone and indicates
when the temporary credential
of the IAM role will expire.
Now, let's set a temporary credential
to environment variables
as it has a higher precedence than the profile we created
using "aws configure" command.
Here will be what looks like an annik system
and for Windows you will use a set command
rather than an export.
Now, let's verify the subsequent CLI commands
I will invoke as the test role
while using this command.
The output should contain the role ARN,
similar to the Assumed Role with the CLI Session
instead of the previous, the user ARN.
We will confirm that the IAM user has now
read-only access to ec2 instances
by running the same command
and here we can see there is
an unauthorized operation error as expected.
And we will confirm that the IAM role
has the read-only access to RDS DB instances
by running the command.
Now we can see the list of database RDS instances
is shown on the command.
Finally, we can return to the IAM user
by removing the environment variables.
This is essential when the temporary credential has expired.
Run this command to clear or remove
the environment variables.
For Windows, you might be using the set command
as the floating box shows.
And we can verify the CLI commands
are being invoked by the test user
using this command.
The manual process we showed earlier
can give you a good understanding
of how an IAM role can be assumed by using the AWS CLI
and a sample apprised to scripting or SDK deferments.
If you are after a quicker way to switch a role
in the AWS CLI, you are only a few steps away.
First, let's open the AWS CLI config file
in the .aws/config.
So, after open the file in the vim editor,
you can see at the moment I only have a default profile
with a region specified to Sydney region,
ap-southeast-2.
And we will add the following to the end of the file,
which creates a new name profile
called "test-role-profile"
this is the same role ARN we used
in the previous CLI command.
Using the default profile from the copy file
to assume the role.
If you use a different name profile
to store the test user's credentials,
then you can change the source profile accordingly.
Now, you can save this file using the wq again.
Now we can try to verify
if the role has been successfully switched
using this command.
And you can see the role session names
that start with a botocore-session
for ease of tracking.
Lastly, we can render AWS CLI command
to describe RDS instances,
which should give us the same output
as long as we include the name profile
in the command line.
Thanks for watching and happy cloud computing
from all of us here at AWS.
(upbeat music)