why do you need roles (as opposed to IAM groups) to access resources in another AWS account?

user_7355970 0
Viewed 368

I am trying to understand why you need IAM "roles" to access a resource in a different IAM account, and why AWS can't just do the same thing with IAM groups.

Whenever I ask people this question the conversation just seems to go in circles:
Them: "To grant access to a resource to users in another IAM account, you have to give them permission to assume an IAM role, and then grant that IAM role access to your resource."
Me: "I understand that, but why can't you just create an IAM group that can access that resource, and then add those users from the other account to your IAM group?"
Them: "You can't add users from another AWS account to an IAM group in your account."
Me: "I understand that too, but why does AWS only let you do cross-account permissions like that by using roles? Why wouldn't it make just as much sense for AWS to let you create an IAM group and then let you add IAM users from other accounts into that group?"

There's probably some simple one-sentence piece of information that explains why it has to be this way, and once someone tells you, it all makes sense, but it's not in the documentation and I don't know what it is. What is it?

amazon-iam amazon-web-services
2 Answers

I would say security is main reason. IAM roles provide only temporary credentials. Using such credentials whenever possible is good practice for security reasons.

Off course you can also create IAM user in your account, and give the associated access keys to people form the other account. And sometimes this is preferred, e.g. to enable read access only to some resources. But the issue is that IAM user credentials are permanent, unless manually disabled or deleted. For security reasons giving away permanent credentials to your account is not a recommended practice.

From docs:

We recommend using this approach to enforce the principle of least privilege. That means restricting the use of elevated permissions to only those times when they are needed for specific tasks. With roles you can help prevent accidental changes to sensitive environments, especially if you combine them with auditing to help ensure that roles are only used when needed.

user_2488230

The one-sentence answer is that Amazon chose to do it that way.

From an operational perspective, it simplifies life considerably if you associate an access key with an account. The alternative is to specify an account separately with every request.

From an organization management perspective, trees are easier to understand than forests. What I mean by that is that everything branches off the account's IAM root. If you allow arbitrary users across the AWS universe to have access to arbitrary resources within arbitrary accounts, you end up with a management nightmare.

As a sidebar to that last comment, the early AWS services had resource-based policies. These are now discouraged in favor of identity-based policies, and newer services don't have resource policies.

Lastly, from a security perspective, a multi-tenant environment is a lot easier to control if you establish a hard wall around each tenant.

user_134007290
Related