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.
Related
AWS Elasticsearch fine grained access control uses Open Distro Elasticsearch security. Using this feature authorization can be handled inside the Elasticsearch. https://opendistro.github.io/for-elasticsearch-docs/docs/security/access-control/users-roles/#create-roles
AWS Documentation suggests to use the Open Distro Elasticsearch documentation, to use security Rest APIs, such as creating role or reading role.
You can create new roles for fine-grained access control using Kibana or the _opendistro/_security operation in the REST API. For more information, see the Open Distro for Elasticsearch documentation.
https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/fgac.html
There are roles inside Elasticsearch using which we can control the authorization permissions of IAM user/role. This is done using Role mapping by adding IAM user into Users list or IAM role into backend role.
I added my IAM role into Elasticsearch backend role and I am able to execute below APIs,
PUT /my_index
PUT /_template/template_for_my_index
But when I execute below API, I am getting below response.
PATCH /_opendistro/_security/api/rolesmapping/my_role_inside_elasticsearch
{'statusCode': 200, 'headers': {'Access-Control-Allow-Origin': '*'}, 'isBase64Encoded': False, 'body': '{"status":"FORBIDDEN","message":"No permission to access REST API: User arn:aws:iam::123456789:role/myIamRole with Open Distro Security Roles [all_access] does not have any role privileged for admin access. No ssl info found in request."}'}
I tried adding IAM role into Elasticsearch all_access and also into my own Elasticsearch role which has * permissions(all permissions).
How to grant access to IAM Role/User to create role inside AWS Elasticsearch?
Note: IAM Roles and Elasticsearch Roles are different.
To grant permission to an IAM user/role to access opendsitro apis, you have to give the IAM entity permissions similar to master user. You have two options to do so:
Either make that IAM entity the new master user via aws opensearch cli/console.
Map the IAM user/role to all_access as well as security_manager thereby adding it as an additional master user.
Note: For IAM user, the arn needs to be added under users, whereas for IAM role, the arn needs to be added under backend_roles in the role mapping section.
More details: https://docs.aws.amazon.com/opensearch-service/latest/developerguide/fgac.html#fgac-more-masters
Can you clarify if you were able to successfully map the IAM user/role to all_access? Your question is not clear on that.
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.
How do ECR policies differ from IAM policies?
The language around the ECR policies seem to indicate it is similar to the S3 bucket policy.
Does it allow you to grant access not using IAM?
If I wanted to grant another account access to registry can I use an ECR policy or do I still need a cross account role?
The language around the ECR policies seem to indicate it is similar to the S3 bucket policy.
Yep, they are. Both ECR repository policies and S3 bucket policies control permissions of specific resources rather than permissions of principals (identities). In the case of ECR, it lets you define permissions for a specific repository.
Does it allow you to grant access not using IAM?
Sort of. You need both an IAM policy and a repository policy to express some kinds of permissions. For example, an IAM policy on a user might have permissions like ecr:* in order to allow the user to make API calls to ECR and then a repository policy might grant control over a particular repository.
If I wanted to grant another account access to registry can I use an ECR policy or do I still need a cross account role?
This is one of the primary use-cases of repository policies. A user in account A might have permission to make ECR API calls with ecr:* in the IAM policy. A repository in account B could then grant cross-account access to account A, at which point the account A user does not need to assume a cross-account role in order to access the repository.
According the documentation, you can allow cross-account access to your ECR with just the repo policy:
For Principal, choose the scope of users to apply the policy statement to.
You can apply the statement to all authenticated AWS users by selecting the Everybody check box.
You can apply the statement to all users under specific AWS accounts by listing those account numbers (for example, 111122223333) in the AWS account number(s) field.
You can apply the statement to roles or users under your AWS account by checking the roles or users under the All IAM entities list and choosing >> Add to move them to the Selected IAM entities list.
So you don't need to setup cross-account role assumption, but I imagine you would have to grant the appropriate permissions to the users/groups/roles in the remote account to allow them to talk out to your ECR.
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.
I am looking to use AWS STS to access resources from another AWS account owned by another team.
say, AWS Account A trying to access AWS Account B.
basically the steps I am following:
1. Create a user in Account A
2. Create Role in Account B with the necesaary permissions
3. Add assume role permissions for user in Account A
4. Use User credentials to get temporary credentials for Account B.
5. Use temp credentials on Account B.
But, after reading through a ton of AWS docs, I am unable to figure out which account gets billed for the cross account API calls?
When you use AssumeRole to grant access to another Amazon account (account B), your identity switches to the other account with the username being the role name that you assumed.
The only cross account API being called will be AssumeRole. After this succeeds you will be using the APIs using account B's temporary credentials that were returned from AssumeRole.
All ownership, billing, etc. will be the same as if you had originally logged into account B as a normal IAM user except for the user name.
CloudTrail records STS type calls such as AssumeRole and logs all authenticated API requests. Once AssumeRole succeeds, your activity (using the temporary credentials) will be logged by CloudTrail in account B. This assumes of course that CloudTrail is enabled.
This link will give you more details into the user identity that AWS uses when using AssumeRole.
CloudTrail userIdentity Element
When you create a role for cross-account access, you establish trust from the account that owns the role and the resources (trusting account) to the account that contains the users (trusted account). To do this, you specify the trusted account number as the Principal in the role's trust policy. That allows potentially any user in the trusted account to assume the role. To complete the configuration, the administrator of the trusted account must give specific groups or users in that account permission to switch to the role.
Link
As everyone has mentioned a user from the account A is just assuming a role in account B to temporary access resources in account B,ownership stays still and the owner pays for the resources he owns. In this case it is the account B who pays. STS is the service being used to assume a role and is part of IAM.
The following was taken from IAM FAQ.
Q: How do I assume an IAM role?
You assume an IAM role by calling the AWS Security Token Service (STS) AssumeRole APIs (in other words, AssumeRole, AssumeRoleWithWebIdentity, and AssumeRoleWithSAML). These APIs return a set of temporary security credentials that applications can then use to sign requests to AWS service APIs.
Q: How many IAM roles can I assume?
There is no limit to the number of IAM roles you can assume, but you can only act as one IAM role when making requests to AWS services.
Q: Who can use IAM roles?
Any AWS customer can use IAM roles.
Q: How much do IAM roles cost?
IAM roles are free of charge. You will continue to pay for any resources a role in your AWS account consumes.