AWS IAM 角色与组

Question

AWS官网将角色解读为权限的集合，将组解读为用户的集合。 但他们对我来说仍然是一样的。 您将策略附加到组或角色，然后将组或角色分配给用户。 角色和组之间到底有什么区别？

Answer 1

谷歌员工的简短回答：您不能为用户分配角色。

• 组是一组具有相同策略的用户
• 角色是服务策略的预设

用户可以根据 AWS 文档担任角色：

担任角色

Answer 2

AWS 组是标准组，您可以将其视为多个用户的集合，并且一个用户可以属于多个组。

AWS IAM 角色都是不同的物种； 他们像个人用户一样操作，只是他们主要以模拟方式工作，并在不指定凭证的情况下与 AWS API 调用进行通信。

鉴于 IAM 角色略有不同，我只强调这一点。 IAM 角色有多种类型，例如 EC2 IAM 角色、Lambda 等。如果您考虑，可以使用 EC2 IAM 角色启动 EC2 实例； 因此，任何与 AWS API 相关的通信都不需要任何 AWS 访问密钥或密钥进行身份验证，而是可以直接调用 API（但长答案是 - 它使用 STS 并在幕后不断回收凭证）； 它可以做什么的特权或权限由附加到 IAM 角色的 IAM 策略确定。

Lambda IAM Role 的工作原理完全相同，只是只有 Lambda 函数可以使用 Lambda IAM Role 等。

Answer 3

用户：最终用户（想想人）。

组：一组权限下的用户集合（权限作为策略）。 根据 IAM 标准，我们创建具有权限的组，然后将用户分配给该组。

角色：您创建角色并将它们分配给 AWS 资源（ AWS 资源示例可以是客户、供应商、承包商、员工、EC2 实例、AWS 之外的一些外部应用程序），但请记住您不能将角色分配给用户。

不仅用户会登录，有时应用程序也需要访问 AWS 资源。 例如，一个 EC2 实例可能需要访问一个或多个 S3 存储桶。 然后，需要创建一个 IAM 角色并将其附加到 EC2 实例。 该角色可以被不同的 EC2 实例重复使用。

记住：团体是为了生活。 角色是非生命的。

Answer 4

请注意，组特定于非联合的本地 IAM 用户，并且本地 IAM 用户日志不显示谁执行了这些操作（即，多个人或应用程序可以使用相同的长期密钥/访问密钥，并且没有哪个实体使用它们的记录）。 如果您必须使用本地 IAM 用户，您可以将它们放入 IAM 组。 这可能特别有用的地方是用作边界——您可以在组上放置拒绝策略，限制对特定服务或操作的访问，并且该拒绝策略将应用于组中的所有用户。

相反，可以联合角色，而本地 IAM 用户则不能。 例如，您可以创建一个用作成员容器的本地 AD 组，然后该 AD 组的成员（并且只有他们）可以使用与 AD 组相关的角色，以及任何允许或拒绝策略和/或您已应用于角色的权限边界。 （ 这是一个解释 AWS ADFS 联合的链接。）

重要的是，角色允许临时会话凭证（这是最佳安全实践），因为它们的会话令牌最多在 12 小时后过期。 同样重要的是，角色确实会在日志中显示哪些 AD 成员有权使用该角色实际执行了该操作。 您会发现这被附加到日志中角色 ARN 的末尾（例如，用户 ID）。 CloudTrail 将是指示用户活动的多种服务之一。 从日志记录的角度来看，这很重要。

Answer 5

我一直对这两个功能之间的区别感到困惑。

简而言之，

角色就像一个带有所有预设策略的标签，可以附加到 IAM 用户/组或 AWS 服务上。 IAM 用户与账户根用户 (Admin) 共享同一个账户，但由根用户分配了使用该账户内 AWS 资源的权限。

因此，IAM 用户可以直接与 AWS 服务交互； 虽然 IAM 角色无法直接向 AWS 服务发出请求，但它们应由授权实体（如 IAM 用户或实例）承担。 https://aws.amazon.com/iam/faqs/

Answer 6

我认为 AWS 角色是一种“sudo”，其中每个 AWS 角色可以临时提供一组非常特定的提升权限，但不需要提升的凭证。 我的印象是，与 sudo 一样，AWS 角色试图防止特权操作被意外使用。 我很想知道其他人是否同意这个类比。

Answer 7

一次只能担任一个 IAM 角色！ 有几种情况正好适合这种许可。

阅读常见问题解答：我可以担任多少个 IAM 角色？

使用的底层工具在两个用例中都是“权限”，即：组和 IAM 角色。

组或 IAM 角色-->有策略-->策略定义权限 -->权限分配给组或 IAM 角色。

Answer 8

我很难理解给定答案的精神。

这是我发现的：

---

团体：

• 旨在代表在 IAM 中创建的需要相同策略的人类用户。

  • 前任。 Dev 1 - Dev 8都是开发人员，都需要访问来创建开发服务器。
  • 这类似于传统的桌面用户/组，但仅适用于人类用户。

---

角色：

Roles轮换自动凭据，这意味着访问策略不需要输入密码。

这对两件事有好处：

1. 授予非人类权限，例如服务/应用程序。

   • 前任。 EC2 of type A需要访问S3 of type B 。

2. 向联合/外部用户和组授予权限。

   • 前任。 Contractor A @ Outside Company A需要访问您的Server A 。
     • 用户和组的身份验证由某些服务处理，例如 Azure AD。
     • 然后将授权映射到您的 IAM role(s) ，而不是users或groups 。

       • 注意：我使用 Jumpcloud 的文章和 AWS 的文档来收集这些信息。 术语“组”、“角色”和“用户”在 SSO+IdP 和 IAM 的上下文中变得超载。

       • 这是一张显示他们如何映射roles的图像。 ！ 需要 10 声望 :(

旁白：有一种将Roles分配给普通 IAM Users和Groups的方法，但这似乎是不好的做法。

---

希望这可以清楚地说明上述答案。

Answer 9

了解 IAM 角色与 IAM 组（IAM 身份）是非常重要的基础概念。 重要的是要了解 IAM 角色和 IAM 用户之间的区别，因为本质上组只是一群执行类似功能的用户（例如，一组开发人员、QA 等）。角色并不是与一个人（用户）唯一关联的，他们可以是由需要它在那个时间点（会话）执行任务的用户、资源或服务承担。 角色不提供密码或访问密钥等长期凭证。 最佳实践建议是要求工作负载使用具有 IAM 角色的临时凭证来访问 AWS

请参阅下面的链接以获得更清楚的信息： https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html