【发布时间】：2016-08-27 18:32:26
【问题描述】：
AWS 官方网站将角色理解为权限的集合，将组理解为用户的集合。但在我看来，它们仍然是一样的。您将策略附加到组或角色，然后将组或角色分配给用户。角色和组之间究竟有什么区别？
【问题讨论】：
【发布时间】：2016-08-27 18:32:26
【问题描述】：
【讨论】：
-
you can't assign role to user 是让我意识到它们之间区别的关键语句。角色是一种无需为其创建用户即可向某人（客户、供应商、承包商、员工、EC2 实例、AWS 外部的某些外部应用程序尝试使用您的服务）提供权限的方式。
-
对我来说，IAM 角色似乎涵盖了 IAM 组的所有用例。每当您想要一个用户的 IAM 组时，只需创建一个具有相同策略的 IAM 角色并让用户担任该角色。那我们为什么需要 IAM 组呢？
-
将角色“分配”给用户和用户“承担”角色有什么区别？我也不会说您可以将组分配给用户。
-
@papiro 假设是临时手动操作，而添加到组是永久性操作
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 等。
【讨论】：
-
这是不正确的。具有 IAM 角色的 EC2 实例仍使用访问密钥；但是这些是从实例元数据中检索的（使用 SDK 自动或手动），并且寿命很短。更多详情docs.aws.amazon.com/AWSEC2/latest/UserGuide/…
-
谢谢你，克里斯 - 我已经更新了答案。我最初的意图是强调不需要干预访问密钥和秘密。
-
@chris So.. 在 AWS 世界中，我可以说，不能将策略（比如 S3FullAccess）应用于服务（比如 EC2）以访问另一服务（比如 S3）吗？
-
@overexchange：这完全是倒退。您可以创建一个 EC2 角色，将其分配给一个实例，并将一个或多个策略与该角色相关联。然后该实例将能够执行该角色授予的任何操作 - 因此在您的示例中，如果与 ec2 实例关联的角色具有 S3FullAccess，则 EC2 实例将具有完全 S3 访问权限。
-
@NaveenVijay 对我来说，角色和组看起来都一样。两者都用于表示一组策略。一方面，许多“受信任的实体”被分配一个或多个角色，另一方面，许多“用户”被分配到一个或多个组。什么组适用于用户，角色适用于受信任的实体。
用户：最终用户（Think People）。
组：用户集合在一组权限下（权限作为策略）。根据 IAM 标准，我们创建具有权限的组，然后将用户分配给该组。
角色：您创建角色并将它们分配给 AWS 资源（AWS 资源示例可以是客户、供应商、承包商、员工、EC2 实例、AWS 之外的一些外部应用程序）但请记住，您不能为用户分配角色。
不仅用户会登录，有时应用程序也需要访问 AWS 资源。例如，一个 EC2 实例可能需要访问一个或多个 S3 存储桶。然后，需要创建一个 IAM 角色并将其附加到 EC2 实例。该角色可以被不同的 EC2 实例重复使用。
记住：团体是为了生活。角色是非生命的。
【讨论】：
-
那么做什么你分配角色？
-
第 3 点，您创建一个角色并分配给 AWS 资源。
-
对不起，我的意思是不评论上述答案，而不是你的。现在我看到了你的，很清楚。
-
不是“客户、供应商、承包商、员工”==IAM 用户吗？如果没有，怎么办？
我一直对这两个函数之间的区别感到困惑。
总之，
角色就像一个标签，其中包含可以附加到 IAM 用户/组或 AWS 服务的所有预设策略。 IAM 用户与账户根用户 (Admin) 共享同一个账户，但由根用户分配了使用该账户内 AWS 资源的权限。
因此，IAM 用户可以直接与 AWS 服务交互；虽然 IAM 角色无法直接向 AWS 服务发出请求，但它们应由授权实体（如 IAM 用户或实例）承担。 https://aws.amazon.com/iam/faqs/
【讨论】：
我认为 AWS 角色是一种“sudo”，其中每个 AWS 角色可以临时提供一组非常特定的提升权限，但不需要提升的凭证。我的印象是，与 sudo 一样，AWS 角色试图防止特权操作被意外使用。 我很想知道其他人是否同意这个类比。
【讨论】：
请注意，组特定于本地 IAM 用户，它们不是联合的，并且本地 IAM 用户日志不显示谁执行了这些操作（即，多个人或应用程序可以使用相同的长期秘密/访问密钥，并且没有哪个实体使用它们的记录）。如果您必须使用本地 IAM 用户，您可以将他们放入 IAM 组。这在作为边界特别有用的地方 - 您可以在组上放置拒绝策略，限制对特定服务或操作的访问，并且该拒绝策略将应用于组中的所有用户。
相反，角色可以联合，而本地 IAM 用户则不能。例如，您可以创建一个用作成员容器的本地 AD 组，然后该 AD 组的成员（并且只有他们）可以使用与 AD 组相关的角色，以及任何允许或拒绝策略和/或您已应用于角色的权限边界。 (Here is a link explaining the AWS ADFS federation.)
重要的是，角色允许临时会话凭据（这是最佳安全做法），因为它们的会话令牌最多在 12 小时后过期。同样重要的是，角色do会在日志中显示哪些 AD 成员有权使用该角色实际执行了该操作。您会发现这已附加到日志中角色 ARN 的末尾（例如，用户 ID）。 CloudTrail 将是指示用户活动的多种服务之一。从日志记录的角度来看，这很重要。
【讨论】：
一次只能担任一个 IAM 角色！而且有几个 完全符合这种许可的情况。
Read the faq about: How many IAM roles can I assume?
使用的底层工具在两个用例中都是“权限”，即：组和 IAM 角色。
组或 IAM 角色 --> 有策略 --> 策略定义权限 --> 权限分配给一个组或 IAM 角色。
【讨论】：