Difference between IAM role and IAM user in AWS

Question

What is the difference between an IAM role and an IAM user? The IAM FAQ has an entry explaining it, but it was vague and not very clear:

An IAM user has permanent long-term credentials and is used to directly interact with AWS services. An IAM role does not have any credentials and cannot make direct requests to AWS services. IAM roles are meant to be assumed by authorized entities, such as IAM users, applications, or an AWS service such as EC2.

I think an IAM role is used for federated logins (using an IdP with SAML tokens for example), and they don't have permanent access keys that you can download like regular IAM users have (the "an IAM role doesn't have any credentials" part).

What do they mean when they say an IAM role can't make direct requests to AWS services? I can login to AWS Console (the web console) and create stacks etc, so it can't be that.

Answer 1

To understand the difference, let us go through IAM basic knowledge

IAM controls: Who (authentication) can do What (authorization) in your AWS account. Authentication(who) with IAM is done with users/groups and roles whereas authorization(what) is done by policies.

Here the term

• User - End user think about people

• Groups- a set of users under one set of permission(policies)

• Roles - are used to grant specific permission to specific actors for a set of duration of time. These actors can be authenticated by AWS or some trusted external system.

User and roles use policies for authorization. Keep in mind that user and role can't do anything until you allow certain actions with a policy.

Answer the following questions and you will differentiate between a user and a role:

• Can have a password? Yes-> user, No-> role
• Can have an access key? Yes-> user, No-> role
• Can belong to a group? Yes-> user, No -> role
• Can be associated with AWS resources (for example EC2 instances)? No-> user, Yes->role

AWS supports 3 Role Types for different scenarios

• AWS service roles (for example: EC2, Lambda, Redshift,...)
• Cross-Account Access: granting permissions to users from other AWS account, whether you control those account or not.
• Identity Provider Access: granting permissions to users authenticated by a trusted external system. AWS supports two kinds of identity federation: - Web-based identity such as Facebook, Goolge- IAM support ingeration via OpenID Connect - SAML 2.0 identity such as Active Directory, LDAP.

To understand what role is, you need to read its use case, I don't want to reinvent the wheel so please read the following AWS documents: https://aws.amazon.com/blogs/security/how-to-use-a-single-iam-user-to-easily-access-all-your-accounts-by-using-the-aws-cli/

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html

Hope it helps.

Answer 2

Main actors in IAM are users, groups, roles and policies. And what you need to understand about AWS and never forget is that

Everything in AWS is an API

And to execute any API or any of its methods, first we have to authenticate and then authorize that particular user/group/role.

Ex: An operator wants to put an object to a S3 bucket. This process happens through a set of API calls within AWS. Basically we call the S3 API and a method of it to put the object into the particular bucket (say method put_object_in_s3). For that we may want to provide the name of the bucket, the object, and most importantly we need to provide set of credentials (username with password or secret key or etc) in order to tell the AWS API Engine who this user/group/role is.

The first thing API Engine does is, look at those credentials sent with the API. Then it validate those (whether they are correct, active) credentials indicating that this request is coming from a actual valid user, group or role. Then what the API Engine does is (as it now knows who sent this API request) it takes the policy documents associated with the particular operator (user or role) and evaluate them as a single view. That is we check whether the action called in the API is authorized for that operator.

IAM user - In the context of IAM, an user is a “permanent” named operator (human or machine). What’s important to note is that it’s credentials (credentials maybe username password or access key or a secret key) are permanent and stays with that named user. So by that AWS knows that what are the authentication methods (username password authentication method or secret key method or etc) for this user (as its permanent and stays with the user).

IAM group - As in the above image, a group is a collection of users. And note that a user can be in many groups as well.

IAM roles - Roles are not Permissions !!!. A role is also an authentication method just as IAM users and groups. As an user, a role is also a operator (could be a human, could be a machine). Difference is that credentials with roles are temporary.

Policy Documents - As stated earlier, roles are not Permissions. Permissions in AWS are completely handled by objects called Policy Documents. Policy Documents are JSON documents. Policy Documents can directly be attached to Users, Groups or Roles. When a policy document gets attached to any of above operator, then only they get permissions do stuff. A policy document lists things like: Specific API or wildcard group of APIs that gets whitelisted against which resources, and Conditions for those API executions (like allow only if this user, group or role in the home network or allow from any location, allow only at certain times of day and etc)

Last but not least, Authentication in AWS is done via (IAM users, groups and roles) whereas Authorization is done by Policies.