AWS IAM Role vs Group - amazon-web-services

The AWS official site reads role as a collection of permissions and group as a collection of users. But still they look the same to me. You attach policies to groups or roles, and then assign groups or roles to a user. What exactly are the differences between role and group?

Short answer for googlers: you can't assign role to user.
group is a bunch of users with the same policies
role is a preset of policies for service(s)
Users can asume roles according to AWS docs:
Assuming a Role

AWS Groups are the standard groups which you can consider as collection of several users and a user can belong to multiple groups.
AWS IAM Roles are all together different species; they operate like individual users except that they work mostly towards the impersonation style and perform communication with AWS API calls without specifying the credentials.
Given that IAM Roles are little different, I am emphasizing only that. There are several types of IAM Roles like EC2 IAM Roles, Lambda etc. If you consider, you can launch an EC2 instance with an EC2 IAM Role; hence forth any AWS API related communication wouldn't require any AWS Access Key or Secret key for authentication rather can call the APIs directly (however the long answer is - it uses STS and continuously recycles the credentials behind the scenes); the privileges or permissions of what it can do is determined by the IAM Policies attached to the IAM Role.
Lambda IAM Role works exactly the same, except that only Lambda function can use the Lambda IAM Role etc.

Users: End User (Think People).
Groups: A collection of users under one set of permissions (permission as policy). As per IAM standards we create groups with permissions and then assign user to that group.
Role: you create roles and assign them to AWS resource (AWS resource example can be a customer, supplier, contractor, employee, an EC2 instance, some external application outside AWS) but remember you can't assign role to user.
It’s not only users who will login, sometimes applications need access to AWS resources. For example, an EC2 instance might need to access one or more S3 buckets. Then, an IAM role needs to be created and attached to the EC2 instance. That role can be re-used by different EC2 instances.
Remember : Groups are for living. Roles are for non-living.

I think of an AWS Role as a kind of 'sudo', where each AWS Role can temporarily provide a very specific set of elevated privileges, but without needing the elevated credentials. I get the impression that like sudo, AWS Roles try to prevent privileged actions being used accidentally.
I'd be interested to hear if others agree with this analogy.

Please note that Groups are specific to local IAM users, which are not federated, and local IAM user logs do not show who has done the actions (i.e.., multiple people or applications could use the same long-term secret/access keys, and there is no record of which entity used them). If you must use local IAM users, you can place them into IAM Groups. Where this can be especially useful is to serve as a boundary -- you could place a deny policy on the group, restricting access to specific services or actions, and that deny policy will be applied to all users in the Group.
Conversely, roles can be federated, whereas local IAM users are not. You might create an on-premises AD group that serves as a member container, for example, and then the members of that AD group (and only they) can use the role that the AD group correlates to, with whatever allow or deny policies and/or permissions boundaries you've applied to the role. (Here is a link explaining the AWS ADFS federation.)
Importantly, roles allow for temporary session credentials (which is a best security practice), as their session tokens expire after a maximum of 12 hours. Equally importantly, roles do show in the logs which of the AD members with access to use the role actually did the action. You'll find this tacked to the end of the role ARN in the logs (e.g., a user ID). CloudTrail would be one of several services that indicate user activity. This is important from a logging standpoint.

Understanding IAM roles vs IAM groups (IAM indentities) is very important foundational concept . Its important to look at difference between IAM role and IAM user as essentially group is just a bunch of users performing similar functions (eg. group of developers, QA's etc.) Roles are not uniquely associated with one person (user), they can be assumed by user,resource or service who needs it to perform task at that point of time (session). Roles do not provide long-term credentials like password or access keys.
Best practice recommendation is to require workloads to use temporary credentials with IAM roles to access AWS
Please refer to link below for more clarity:
https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html

I was confused all the time about the difference between these two functions.
In short,
Role is like a tag with all the preset policies that can attach on IAM users/groups or AWS services. IAM users share the same account with the account root user (Admin) but with assigned permissions by the root user to use AWS resources within that account.
Therefore, IAM users can directly interact with AWS services; whereas IAM roles cannot make direct requests to AWS services, they are meant to be assumed by authorised entities like an IAM user or an instance. https://aws.amazon.com/iam/faqs/

I had a hard time deciphering the spirit of the given answers..
Here's what I've found:
Groups:
Intended to represent human users created within IAM who need identical policies.
Ex. Dev 1 - Dev 8 are all developers, and all need access to create dev servers.
This is similar to traditional desktop users/groups, but for HUMAN users only.
Roles:
Roles rotate automatic credentials, meaning password input isn't needed for accessing policies.
This makes it good for two things:
Giving permissions to non-humans, such as services / applications.
Ex. EC2 of type A needs access to S3 of type B.
Giving permissions to federated / outside users & groups.
Ex. Contractor A # Outside Company A needs access to your Server A.
Authentication of users & groups are handled by some service, like Azure AD.
Authorizations are then mapped to your IAM role(s), NOT users or groups.
Note: I've used Jumpcloud's Article & AWS's Documentation to gather this information. The terms "Group", "Role", and "User" become overloaded in context to SSO+IdP, and IAM.
Here's an image showing how they map roles. !Need 10 Reputation :(
Aside: There is a way of assigning Roles to normal IAM Users & Groups, but it appears to be bad practice.
Hopefully this provides clarity to the answers above.

Only one IAM Role can be assumed at a time! And there are several
situations which fits exactly this kind of permission.
Read the faq about: How many IAM roles can I assume?
The underlaying tool in use is "Permission" in both of the use cases namely: Group and IAM Role.
Group or IAM Role --> Has Policy --> Policy defines permisions --> Permissions are assigned to a Group or IAM Role.

Related

Is it better to use AWS IAM User Group, or IAM Role for users to assume?

So after reading through this: AWS IAM Role vs Group I'm not entirely sure what would be better for a group of users.
We're looking at implementing a group of users with least privileges, but doing it by giving them all a 'dev' role to assume, rather than a group.
This seems reasonable but what's the best practice here? What advantages do AWS User Groups have over Roles or vice versa?
IAM groups and roles, they both serve different purpose.
An IAM group is primarily a management convenience to manage the same set of permissions for a set of IAM users. Groups can be granted permissions using access control policies. This makes it easier to manage permissions for a collection of users, rather than having to manage permissions for each individual user.
IAM roles allow you to delegate access with defined permissions to trusted entities without having to share long-term access keys. You can use IAM roles to delegate access to IAM users managed within your account, to IAM users under a different AWS account, or to an AWS service such as EC2.
Please check out AWS IAM Faqs for more details.

How to Map Users with Groups (IAM) with Organisation Unit?

Related to AWS:
I've been trying to search for an answer about the Users and Groups that I have created using IAM (AWS), how can I map those Groups with the Organization Unit(s)?
For example: I have a Group called 'Developers' where Users (say 5 Users) are member of it.
Now, I have an Organization Unit of 'ApplicationsDevelopment&Services' where I need to give access to 'Developers'. Can I associate Groups with OUs, so that members of that Group get necessary access.
I have some policies (SCP) applied on that OU, to manage the access boundaries of Developers.
Please suggest if there is a way to do it or something else needs to be done like ActiveDirectory setup (whole new setup)?
Thank You,
Varun Gupta
I recommend to have a look into AWS SSO (https://aws.amazon.com/single-sign-on/?nc1=h_ls). It comes with no additional cost, is enabled with one click and lets you easily assign cross-account role access to Groups/Users.
Going with an IAM Group which you like to have access to all accounts inside one OU, create roles inside those accounts with a trust relationship to the user/group account. You can use a CloudFormation StackSet to enroll the Stack on OU level. Allow sts:AssumeRole for the particular group, resource section pointing to the role you deployed through the StackSet (leave the account_id blank).
Then everyone inside the group should be able to assume the role and deployment of the cross-account role is centralized.
AWS Org SCPs have account or OU scope, they are not for individual IAM users or roles. From aws blog:
Central security administrators use service control policies (SCPs) with AWS Organizations to establish controls that all IAM principals (users and roles) adhere to.
At the account level, a similar type of maximum permissions gourds on individual users or roles (not groups) can be set using permission boundries. Thus, if you have any roles mapped to your uses through AD, you can look at attaching permissions boundaries to them. But, note that permissions boundaries are an advanced IAM topic, thus its not clear for me how exactly they would apply to your use-case.

Query regarding AWS IAM Service

Started recently understanding AWS IAM Roles, Groups, Roles and Permissions.
I understood that groups will be added with some Permissions and whoever the users got added into that group, will have an access to those specific AWS services provided in that group. Where as Role is used to provide an access from one Service to Other. (Say Lambda wants to have an access for CloudWatch).
My Query is: Suppose if Group (say 'dev') have added only 2 Permissions policy (say S3FullAccess, LambdaFullAccess)
and Role created for Lambda Service (having Permission policy "cloudwatchFullAccess"), then does a user from 'dev' group can able to access 'cloudwatch' service?
EDIT:
Another query: I didnt understood on How do we map Users/Groups to only specific Roles? orelse does Roles can be accessed by every user/group (assuming Permission policies already added in Groups of those services mentioned in the Roles)? Please clear me this too
The permissions from the role are only allowed by a principal (IAM user/IAM role/AWS Service) that has assumed the role. If your user had the permission to assume that IAM role and did it, then yes they would have those permissions.
However based on the policies they have they cannot assume the role, but Lambda (assuming it has a trust policy in place) can assume the IAM role in question.
This means that Lambda can perform any CloudWatch interactions, which would allow a user within the dev group to add code that interacts with CloudWatch within the Lambda function and then when triggering the Lambda function see the output of it.
They would not however be able to see the CloudWatch interface within the console, or directly interact with it on the AWS CLI.
To explain the difference between users, groups and role:
An IAM user is an entity with which you can interact directly through the console or CLI. It requires credentials to perform these interactions and gains its permissions from policies. It is generally advised not to use these for applications that reside in AWS.
An IAM group is an entity to group similar IAM users, providing them the same permissions. This allows a hierarchy to be easily maintained. No entity can become a group, it is an assignment to an IAM user.
An IAM role is similar to a user, in that it can interact with the console or CLI. However, to do this it must be assumed, which will provide the entity that assumed it with temporary credentials. An AWS service that assumes the role manages these temporary credentials for you.
For a user to assume the role, 2 things would need to be in place. The role would need to have a trust policy that enables the principal of the IAM user (or account) to assume that role. In addition the user would need to have permission to perform the sts:AssumeRole action on the IAM role resource.
More information about this can be found in the Granting a User Permissions to Switch Roles
documentation.

How to check which permissions I have as an IAM user

I'm totally new to AWS and learning about IAM. I was wondering if there is a way around for an IAM user to check what all permission he/she have? Like as a root user, I created a group of IAM users where they were only allowed to use S3 service but once I logged in as an IAM user, it was showing that I have access to other AWS services as well like running EC2 instances, etc which I reckon shouldn't be the case. Thanks!
No, it isn't possible to "show" which services you have access to use, because the policies can be quite complex (eg permission to access an S3 bucket, but only a particular sub-folder if coming from a given range of IP addresses).
You would need to look the the IAM Policies attached to the IAM User, plus the policies on any IAM Groups they are in. Then, some services like Amazon S3 have additional permissions such as Bucket Policies.
In addition, AWS Organizations can limit the permissions of all users within an AWS Account, so even if a user appears to be granted certain permissions, they might not actually be available for use.
In many situations, you'll only know if you can do something by actually trying it. For example, you might have Read Only permissions, which means you can see resources in the AWS Console, but you would receive an error when you try to change things.
All services are available in the AWS Console, but various parts of the console will only work if you have adequate permission.
Note that there's IAM Policy Simulator from AWS. You can select a service and check if a given user has access to any given action (or all actions relevant to a service)

Difference between IAM role and IAM user in AWS

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.
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.
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, a 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 a 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.
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.
You are an IAM User (with some attached IAM Roles).
Think of IAM Roles as capabilities.
You give an IAM User capabilities (e.g. "can create Lambda function", "can upload to S3").
Note on Federated Users:
From http://docs.aws.amazon.com/IAM/latest/UserGuide/id.html:
A role can be assigned to a federated user who signs in by using an external identity provider instead of IAM. AWS uses details passed by the identity provider to determine which role is mapped to the federated user.
So, a federated user is similar to an IAM user which you can attach IAM Roles to. Except that you have an external identity provider.
Technically, you are NOT using a role as your identity when you login to AWS console. You are using your federated user account (with its own attached roles) as your identity.
An IAM user is an account which can be used by a person or an application. A user has credentials to log in and perform actions with the privileges assigned to that account.
An IAM role is something virtual that a resource can assume. For example, an EC2 instance can assume a role and execute AWS command with that assigned privileges. The same goes for other services like API gateway, Lambda, Kinesis, RDS and so on.
What do they mean when they say an IAM role can't make direct requests to AWS services?
The role itself is not able to perform any tasks since it has to be assumed by somebody or something. Somebody can also be someone logged in through identity federation and then assume a role.
I am practically new to AWS but I have implemented similar concepts in backend applications. Therefore, I would make an attempt to simplify this more from a newbie perspective.
IAM User - This is an actual account registered into the AWS IAM platform. This means that this is a person/application that is an actual entity. Note that this entity can do nothing, just an existence. Like when I signup for an application, my user entity is created and I can log in with provided credentials and have a profile.
IAM Group - This is a collection of specific users. Although this can also give identity, the focus is on the specific individuals that make the group. For example, how we group employees into departments in organizations based on their specific specialities and skillsets.
IAM Policies - This part seems easiest to understand. This is a specific rule/permission/access to a resource spelt out in clear dos and don'ts in a JSON format. Each policy is about a particular resource. A resource can be anything from an EBS volume, a Lamda Function, or even IAM itself.
IAM Role - This is like a title with specific responsibilities, i.e. a group of policies(permissions/access) that anyone with this title will have. For example, if we have a title of "Note-Taker", anyone from different departments can be assigned this title temporarily for a meeting, a period etc. And only those with this permission will be able to access the note-taking app. However, we can have some roles that will fit well with a group, e.g. all members of the accounting department can have the title of an accountant, which gives access to the books of account. But we can have another title of director, which has access to delete books of account, and this will cut across all departments.
Federated Users - These are entities also, but with no profile in the company(IAM). They are like contractors who can be assigned certain roles or titles through an acquired trust from the Federating platform as well as the access due to those titles. The good thing is that if the Federating platforms replace a user, there would be no reason to deactivate the old user and give access to the new one because the platform is the one with the access and not the "user".
IAM User - An user/application accessing AWS Resources
IAM Roles - Set of permissions/policy that can be applicable to an user or resource.
You can apply Roles to IAM user and to an AWS Resource too.
E.g., Apply IAM Role to Lambda Function. Function can only with that IAM Role.
IAM role is an entity which has specific access defined by the policy. And that access is. It doe snot have the permanent creds (Access keys and Secrets Access Keys)- it works on the "AssumeRole" method where token is granted for accessing the different AWs resources.
IAM User has the permanent access keys and secret access keys, we can define the permissions on the resources , IAM ROLE can be assumed by the IAM USER , as it has the keys - it can have access to the resources all the time...
IAM Policy (permissions- read,write etc.) apply to User,Group and Roles.
User- when a user want to access anything in AWS cloud, it must have IAM policy assigned.
Group - when a group of users is assigned with common IAM policy.
Roles - It needs when a service want to access another service. Service must be assigned with role that have policy assigned to perform certain actions in the AWS cloud. In other words, We can't directly assign policies on Service, first we need to create Role and then assign policy on that role.
Note: Roles are intended to be not used by physical people, instead use by AWS services only.