So after reading through this: <AWS IAM Role vs Gr...
# awsm
mysterious-wolf-74677
05/11/2021, 6:43 PMSo 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?
b
billowy-army-68599
05/11/2021, 6:47 PM
hey there! so the way to really do this depends on how your users authenticate to AWS, are they users you created in the AWS console, or do you use SSO of any kind?
f
fast-vegetable-68654
05/11/2021, 6:50 PMI didn't think you could assign a role to a user. I thought you assigned roles to resources like a group and then assigned users to that group. If that's not the case, then maybe it's not a big deal either way, but honestly groups sound like the right abstraction for your use case.
We're looking at implementing a group of users
m
many-garden-84306
05/11/2021, 7:29 PMFor one thing, groups can only be applied to authenticated IAM users. Other entities that are not IAM users are allows to take on roles. In particular, services and code running within services. For example, you can assign a role to an EC2 instance or ECS container when it runs, and that grants authorization for code inside the instance to access resources.
many-garden-84306
05/11/2021, 7:35 PMIAM users can assume a role with the AWS STS (Secure Token Service) "AssumeRole" API--this returns an independent set of expiring credentials for the role that you can use to make AWS API requires in the context of the role. Using roles, you can create specialized security contexts that may be more limited (or even more permissive) than what an IAM user can do directly.
Groups on the other hand simply aggregate policies onto an IAM user, resulting in a single final set of policies for the user. Any agent with the IAM user's credentials can do anything the user can do.
many-garden-84306
05/11/2021, 7:45 PMIn general, IAM users should correspond to real individual human beings, with varying responsibilities and accountability. They should never share their IAM user credentials or install their credentials on a headless machine/instance. Groups can be used to conveniently assign policy to individual IAM users based on their job requirements. Such policies might include the ability to create new roles or launch instances with specific roles.
Roles should be used whenever code (i.e., an agent) needs access to resources, and that code is running on a box not directly authenticated by an individual human that controls the box.
Roles can also be used by humans (using AssumeRole) when they want to execute actions in a security context different from their default IAM policy. A common example is in an organization with multiple AWS accounts. Policy can be set up to allow an IAM user in one account to assume a role within another AWS account even though that user does not have an independent IAM user identity within the second account.
many-garden-84306
05/11/2021, 7:49 PMRoles can also be used in cases of delegation--e.g., if you have a website that needs access to resources on behalf of of the IAM user logged into the website. It is possible for the user to create temporary, limited role credentials and pass them to the website, allowing the website to work on behalf of the user, without the unsafe practice of the user handing over full IAM user credentials to the website.
many-garden-84306
05/11/2021, 7:59 PMas @billowy-army-68599 suggested, a lot of single signon solutions (I'm only personal familiar with OneLogin) forego the use of IAM users entirely. instead, you log into your single-signon provider and they give you some temporary role credentials that you can use to access AWS resources--or they pass temporary role credentials along to websites you access (including the AWS console), and the website uses those role credentials to access AWS services on your behalf. The role credentials are temporary and need to be refreshed. This is important to note, and one of the main pain-points of this model, because it means that you can't just launch a long-running process on your desktop and go home to sleep. At some point the temporary credentials will expire and you will have to re-authenticate with your SSO provider. This problem may have been alleviated since last I looked at it.
l
little-cartoon-10569
05/11/2021, 8:41 PMOur org's policy is to use only Roles to associate permissions and privileges. The only permissions tied to users or groups are the ones that limit / permit which Roles they can assume. This has worked well for several reasons, not least of which is the consistent code and standards we can apply to all IAM code.
👍 1
m
mysterious-wolf-74677
05/12/2021, 3:08 AM@little-cartoon-10569 that's pretty much the route we're thinking of going. Has there been any complications with it?
l
little-cartoon-10569
05/12/2021, 3:18 AMNo. Some reusable code, and a single account for all our IAM users. One group only: admins.
little-cartoon-10569
05/12/2021, 3:18 AMVery simple to grok.
little-cartoon-10569
05/12/2021, 3:19 AMLots of assume-role configuration, and that's what the reusable code simplifies.