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.
I'm planning to develop a multi tenant platform based on the AWS stack. For each customer, let's call them customerA and customerB I want to create individual resources and restrict them that customerA can't see all stuff from customerB.
The first step to set up for the customer is to set up an IAM user with rights to manage all rights for the user. So I want to give the IAM user the rights to create IAM roles and policies and assign them to users but only for the ARN with the resource name customerA__* as prefix. This way it's possible to give the user the rights to create for example roles giving dynamoDB create table rights with a role name of customerA__rolename as planned but I want to further limit it that all roles also need to be bound to this scope, otherwise customerA__deleteTable could also be used to delete customerBs tables.
So in short: Is it possible to create an IAM role that limits all rights to have the name customerA__xyz and also to limit it's scope for each created role to resources with the name customerA__*
If it's not possible any other suggestions how to set up multi tenant rights for AWS? I don't want to create a separate AWS account for each customer for separation and I doubt this can be automated in a legal way.
Thanks in advance :)
There is indeed functionality for this by writing a permission boundary that prevents an IAM user from actually granting more permissions than they already have (which would allow them to bypass this).
A permissions boundary will be evaluated before the permissions so it will take a higher precedence than any permissions a user can set.
AWS have actually created a thorough policy you can use for this use case on their How can I use permissions boundaries to limit the scope of IAM users and roles and prevent privilege escalation? documentation page.
If you add this within your account you should be able to validate that it provides the functionality that you're expecting.
I share an organization with other members but we are not able to see each other's instances. Is it possible to view and create other member's instances within one organization?
When you create an AWS organization you are not given access to other accounts in the organization automatically. To gain access to resources in another account you create a role in the other account and then "Switch Role" to assume the permissions of that role.
Let's say that you login to account nicknamed "Development". You want to access EC2 instances in the "Production" account. Once you have created a role in the Production account that you can assume, then at the top right of the Amazon Management Console click on your username / account number. A menu appears, then select "Switch Role". If you have previously done this, the previous role will be remembered, otherwise you enter the account number and role name for "Production".
This sounds complicated, but once you do this, it will appear simple and logical. Just remember that when you switch roles, you are temporarily giving up access to one account to obtain access to another account. Your "identity" basically switches. Sort of like the Linux command "su" to switch login identities.
Here is a link to help walk you thru setting up cross account access.
Tutorial: Delegate Access Across AWS Accounts Using IAM Roles
Cloudformation stack for creating cross-account roles
Easing the Creation of Cross-Account Roles for Customers
AWS Organizations are primarily used for consolidated billing. You can apply SCPs to child accounts. You cannot view resources of one account from other account. You can access them using Cross Account IAM roles.
Please read the service description at https://aws.amazon.com/organizations/
I can't seem to find support for a surprisingly relevant issue. There are 10's of AWS services, so I want an AWS policy that restricts our users to only EC2, RDS and API Gateway. How do I do this? Can I 'deny all' and only endorse these specific services?
When you create a new IAM user, the default is all permissions denied.
If you want all users to have the same permissions, create a group. Assign each user to the group. You can also create multiple groups for different types of users.
Amazon has predefined policies that grant varying levels of permissions for each type of service. Select the policies that apply to your goals to the group(s).
Very easy to implement.
You can also create custom policies that define basically anything that you want. IAM policies range from the simple to the very complex.
You'll need to create Managed IAM policies for all users.
Tutorial
Creating IAM Policies
Example Access policies
You can also create Explicit Deny rules
Test IAM policies
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.