I have two roles configured in my IAM called "role1" and "role2" and a user called "foobar". The trust policy of "role2" is configured so that "role1" is granted the AssumeRole action, while "role1" can be assumed by the foobar user.
So the workflow to use role2 would be to login as user foobar, then assume role1 and from there assume role2.
I know that I can easily jump from role1 to role2 in the CLI by setting the source_profile value in the configuration file ~/.aws/config. But I have been unable to do the same thing in the management console (web interface). There is the "Switch Role" menu, but that only allows me to assume the role from the user not logged in, not from an already assumed role.
So my question is: How can I switch to "role2" in the scenario described above from the management console?
I think the transitive IAM Role switch from AWS Console is not allowed as per the documentation
Granting a user permissions to switch roles
When you switch roles in the AWS Management Console, the console always uses your original credentials to authorize the switch. This applies whether you sign in as an IAM user, as a SAML-federated role, or as a web-identity federated role. For example, if you switch to RoleA, it uses your original user or federated role credentials to determine if you are allowed to assume RoleA. If you then try to switch to RoleB while you are using RoleA, your original user or federated role credentials are used to authorize your attempt, not the credentials for RoleA.
Related
Suppose, I am AWS IAM user, is there any way so that I can check what resource permission has been given to me, using CLI or Console.
Unfortunately, there is no comprehensive tool for that. In IAM console you can only check your user's IAM profile or group permission you belong to.
But full set of privileges is a very complex thing to get. Apart from obvious IAM user or group permissions you can have:
IAM roles which you can assume,
resource policies which you are listed as a principle (e.g. bucket policy, kms key policy),
resource policies where a role you can assume is a principle,
cross-account permissions in IAM roles or resource policies,
AWS Organization level SCP permissions.
If the reason for asking this question is related to security, e.g., to check what resources were accessed by a compromised IAM user credentials, you suspend the credentials or delete the user. Also can inspect the CloudTrial history to check what resources a given IAM user accessed.
I use the AWS Console, to switch my role from A to B on the same account (account1). Then I would like to switch from B to role C which is on another account (account2). The switch from A to B is working, but then from B to C is not.
B trusts in arn:aws:iam::account1.id:role/A
C trusts in arn:aws:iam::account2.id:role/B
Is this a limitation of AWS, or should it be possible to switch roles transitively?
I found the answer, it is not possible to switch roles transitively in AWS Console
Based on this AWS documentation:
When you switch roles in the AWS Management Console, the console always uses your original credentials to authorize the switch. This applies whether you sign in as an IAM user, as a SAML-federated role, or as a web-identity federated role. For example, if you switch to RoleA, it uses your original user or federated role credentials to determine if you are allowed to assume RoleA. If you then try to switch to RoleB while you are using RoleA, your original user or federated role credentials are used to authorize your attempt, not the credentials for RoleA.
According to the offical AWS documentation, IAM Roles can also be attached to IAM Users, and not only services.
What would be a valid use case to assign an IAM Role to an IAM User?
Aren't all the cases covered by directly granting (allow/deny) IAM Policies to the users?
TBH my initial impression was thar IAM Roles served the purpose of authorization for the AWS services (so that they can interact with other services), since the latter cannot be addressed in the User context
As you clearly understood, AWS Roles serves the purpose of authentication (with IAM policies for authorization) for AWS services. In contrast, AWS IAM users directly maps towards human user who obtains credentials to login to the AWS Management Console.
However, when granting access to an User outside the AWS Account (e.g; Cross Account Access, AD Authentication Federation) it will require an IAM Role to Assume the permission.
Referring to the documentation you shared, its not a direct IAM User who is getting permission, rather an Active Directory user (External) assuming an IAM Role (Not direct IAM User) to get access to the AWS Resources.
It is an IAM best practice is to assign Roles to AWS users from other AWS accounts in order to delegate permissions. This is to avoid sharing credentials between AWS accounts.
I also wanted to point out, your initial impression about Roles as authorization is not correct. The only IAM resource that is considered authorization are IAM Policies.
This can be seen in the AWS documentation on Understanding IAM and in the following AWS training video: Authentication and Authorization with AWS Identity and Access Management (login required)
The other three basic IAM resources: Users, Groups and Roles are considered part of Authentication.
Question
What does exactly "Assume" a role mean in AWS and where is the definitive definition provided?
Background
Assuming a role is frequently used and trying to understand the definition and what it actually means.
I suppose when a principal (IAM user, application running in an EC2 instance, etc which invokes an action to access AWS resource(s)) needs to invoke an action to access an AWS resource:
AWS (API? or some Authorisation runtime in AWS?) identifies the roles which the principal can be granted. e.g. if an EC2 user is specified to execute the assume-role API call and run an application which accesses an AWS resources in an EC2 instance to which IAM profile is attached, then:
All the IAM roles from the EC2 IAM profile
IAM roles and policies requested in the assume-role call
IAM roles which the EC2 user is granted
AWS finds a role from the roles which has the policy (action, resource) that allows the principle to do the action on the resource.
AWS switches the role of the principle to the role identified.
When the step 3 has happened, it is said "the principal has assumed the role". Is this correct?
Research
Using IAM Roles
Before an IAM user, application, or service can use a role that you created, you must grant permissions to switch to the role. You can use any policy attached to one of an IAM user's groups or to the user itself to grant the necessary permissions.
Assuming a Role
AssumeRole
Using IAM Roles
Using an IAM Role to Grant Permissions to Applications Running on Amazon EC2 Instances
Assuming a role means asking Security Token Service (STS) to provide you with a set of temporary credentials -- role credentials -- that are specific to the role you want to assume. (Specifically, a new "session" with that role.)
You can optionally include a policy with this request, which will serve to limit the permissions of the temporary credentials to only a subset of what the role's policies would have allowed.
You then use these credentials to make further requests. These credentials look similar to IAM user credentials with an access-key-id and secret, but the access key begins with ASIA instead of AKIA and there's a third element, called the security token, which must be included in requests signed with the temporary credentials.
When you make requests with these temporary credentials, you have the permissions associated with the role, and not your own (if you have one) because you have taken on a new identity. CloudTrail can be used to trace the role credentials back to the user who assumed the role, but otherwise the service is unaware of who is using the credentials.
tl;dr: Assuming a role means obtaining a set of temporary credentials which are associated with the role and not with the entity that assumed the role.
AWS (API? or some Authorisation runtime in AWS?) identifies the roles which the principal can be granted.
No. You specify the role you want to assume.
When "you" are code running on an EC2 instance, and the instance has an instance role, the EC2 infrastructure actually calls assume-role on behalf of the instance, and you can fetch the temporary credentials from the instance metadata service. These credentials are accessible only from within the instance, but they are not stored on the instance.
When running a Lambda function, the Lambda infrastructure contacts STS and places your temporary credentials in environment variables. Again, these credentials are accessible to the function, without being stored inside the function.
In either case, you could call assume role with these credentials and assume a different role, but that should not be necessary in most environments.
e.g. if an EC2 user is specified to execute the assume-role API call and run an application which accesses an AWS resources in an EC2 instance to which IAM profile is attached, then:
AWS has no awareness of EC2 users. Instance roles are accessible to everything running on the instance.
All the IAM roles from the EC2 IAM profile
An instance profile can only include one role.
IAM roles and policies requested in the assume-role call
You request to assume exactly one role. You do not need to request a policy -- you only specify a policy if you want the temporary credentials to have fewer privileges than the role credentials would allow. This might be something you would do if you needed code running in an untrusted place -- such as code in a browser or an app -- to be able to sign requests with credentials.
AWS finds a role from the roles which has the policy (action, resource) that allows the principle to do the action on the resource.
No. As noted above, you ask for a specific role when you call assume-role.
AWS switches the role of the principle to the role identified.
No. You make the switch by using the temporary credentials provided.
I have created the following diagram for myself to understand what is exactly assume a role in AWS. Hopefully, you will also find it helpful.
In the diagram, I put it in 3 steps:
Prepare the roles (ExecutionRole and AssumedRole)
Create a Lambda Function on Account A (in your case it is EC2)
Execute the LambdaFunction.
The diagram uses cross-account as an example, if it is within the same account step 1.3 is not required.
Typically, you use AssumeRole within your account or for cross-account access.
...
Users in the same account as the role do not need explicit permission to assume the role. Source: https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html
When step 3 has happened, it is said: "the principal has assumed the
role". Is this correct?
The steps you mentioned in assuming a role are correct.
Here the important point is the IAM role's Trust Relationship configuration where you grant each of the IAM user, application, or service to assume the role. That is where you grant the permission to assume the particular role.
This is important in many aspects, where it controls who can assume the role and it is important to provide not only least access to the role but also grant the least amount of entities who can assume the role.
How would you switch to a user in the AWS console?
I've set up an IAM policy for a user and I'd like to test whether they're working or not.
I've tried switching roles http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html
using the account id from the User ARN (e.g.
arn:aws:iam::<account id>:user/<username>
in
https://signin.aws.amazon.com/switchrole
using:
Account: <account id>
Role: test_user
Display Name: Test User
then clicking Switch Role but I get:
Could not switch roles using the provided information. Please check your settings and try again. If you continue to have problems, contact your administrator.
Note: I am an Admin with full access.
You cannot use the Switch Role functionality to switch to a User.
You have two options:
Login as the User you wish to test, or
Create a Role with the same permissions, switch to the Role, then test
The easiest is to simply login as the user you wish to test. However, this can be a poor security practice because you are using another person's account and any actions you perform would be recorded against that user in Amazon CloudTrail (audit trail).
Alternatively, you could create a new IAM Role and assign exactly the same permissions to that Role. You would also need to assign a Trust Policy to the role to permit it to be used by you (your IAM User). You can then switch to that role in the console. This will work, unless you have any policies that specifically reference the User you wish to test (which will not recognise your Role permissions).
The best way to do this is fully log out of the AWS console. Or you can use a different browser so you can be logged into both at the same time.