IAM角色和IAM用户有什么区别？IAM常见问题解答有一个解释的条目，但它含糊不清，但不是很清楚：
IAM用户具有永久的长期凭证，可直接与AWS服务互动。IAM角色没有任何凭据，也无法直接向AWS服务提出请求。IAM角色应由授权实体（例如IAM用户，应用程序或AWS服务，例如EC2。
）承担。
我认为IAM角色用于联合登录（例如，使用带有SAML令牌的IDP），并且它们没有可以像常规IAM用户一样下载的永久访问键t有任何凭据"部分）。
当他们说IAM角色无法直接要求AWS服务时，这是什么意思？我可以登录AWS控制台（Web控制台）并创建堆栈等，因此不可能。
了解差异，让我们通过IAM基本知识
iam控件：WHO（身份验证）可以在您的AWS帐户中执行（授权）。具有IAM的身份验证（WHO）是使用用户/组和角色完成的，而授权（什么）是由策略完成的。
在这里用语
-
用户 - 最终用户考虑人员
-
组 - 一组在一组许可（策略）下的用户
-
角色 - 用于在一组持续时间内授予特定参与者的特定许可。这些参与者可以通过AWS或一些受信任的外部系统进行身份验证。
用户和角色使用策略进行授权。请记住，在您允许某些策略的行动之前，用户和角色无能为力。
回答以下问题，您将区分用户和角色：
- 可以有一个密码？是 - ＆gt;用户no-＆gt;角色
- 可以有一个访问密钥？是 - ＆gt;用户no-＆gt;角色
- 可以属于一个小组？是 - ＆gt;用户，否 - ＆gt;角色
- 可以与AWS资源（例如EC2实例）关联吗？no-＆gt;用户是 - ＆gt;角色
AWS支持不同方案的3种角色类型
- AWS服务角色（例如：EC2，Lambda，Redshift，...）
- 交叉账户访问：无论您是否控制这些帐户。
- 身份提供商访问：授予由受信任的外部系统认证的用户授予权限。AWS支持两种身份联合会： - 基于Web的身份，例如Facebook，Goolgeiam-通过OpenID Connect提供支持-SAML 2.0身份，例如Active Directory，LDAP。
要了解角色是什么，您需要阅读其用例，我不想重新发明轮子，因此请阅读以下AWS文档：https://aws.amazon.com/blogs/security/how-to-cuse-a-single-iam-user-user-to-aseily-access-access-all-your-accounts-by-by-usis-us--------
https://docs.aws.amazon.com/iam/latest/userguide/id_roles_providers_saml.html
希望它有帮助。
IAM中的主要参与者是用户， groups ，角色和策略您需要了解的是AWS，并且永远不会忘记
AWS中的所有内容都是API
并执行任何API或其任何方法，首先我们必须进行身份验证，然后授权该特定的用户/组/角色。
ex：操作员想将对象放在S3存储桶中。此过程通过AWS中的一组API调用发生。基本上，我们将其称为S3 API，并将对象放入特定存储桶中（例如方法put_object_in_s3）。为此，我们可能需要提供存储桶，对象的名称，最重要的是，我们需要提供一组凭据（带密码或秘密密钥或秘密键或等等的用户名），以便告诉AWS API Engine此用户/group/group/group角色是。
API引擎要做的第一件事是，查看使用API发送的凭据。然后，它验证这些请求来自实际有效的用户，组或角色（无论是正确的，主动）凭证。那么，API引擎的作用是（现在知道谁发送了此API请求），它采用与特定操作员（用户或角色）关联的策略文档，并将其评估为单个视图。也就是说，我们检查API中调用的操作是否已授权为该操作员。
IAM用户 - 在IAM的上下文中，用户是"永久"命名操作员（人类或机器）。重要的是要注意的是，它的凭据（凭据可能是用户名密码或访问密钥或秘密键）是永久的，并且与该命名用户保持联系。因此，通过那个AWS知道该用户的身份验证方法是什么（用户名密码身份验证方法或秘密密钥方法或等）（因为它的永久性并与用户保持联系）。
IAM group - 如上图中，一个组是用户的集合。并请注意，用户也可以分为许多组。
IAM角色 - 角色不是权限！！！角色也是一种身份验证方法，就像IAM用户和组一样。作为用户，角色也是操作员（可能是人类，可能是机器）。差异是凭证是暂时的。
策略文档 - 如前所述，角色不是权限。AWS中的权限完全由称为Policy Documents的对象处理。政策文件是JSON文件。策略文件可以直接附加到用户，组或角色。当策略文档附加到上述操作员的任何一个时，只有他们获得权限才能做事。策略文档列出了以下内容：特定API或通配符的API组，这些API被列入白色的资源以及这些API执行的条件（例如，仅在此用户，组或家庭网络中的角色或从任何位置允许的情况下才允许，仅允许在一天中的某些时间等等）
最后但并非最不重要的一点是，AWS中的身份验证是通过（IAM用户，组和角色），而授权是由政策完成的。
当他们说IAM角色无法直接要求AWS服务时，这是什么意思？我可以登录到AWS控制台（Web控制台）并创建堆栈等，因此不可能。
you 是IAM用户（带有某些IAM角色）。
将IAM角色视为能力。
您提供了IAM用户功能（例如" 可以创建lambda函数"，" 可以上传到S3 "）。
关于联合用户的注释：
来自http://docs.aws.amazon.com/iam/latest/userguide/id.html：
可以将角色分配给联合用户，该用户通过使用外部身份提供商而不是IAM签名。AWS使用身份提供商通过的详细信息来确定哪个角色映射到联合用户。
因此，联合用户类似于您可以将IAM角色附加到的IAM用户。除了您有外部身份提供商。
从技术上讲，登录到AWS控制台时，您不会使用角色作为身份。您正在使用联合用户帐户（带有自己的附件）作为您的身份。
iam用户是一个人可以使用的帐户或申请。用户具有凭证登录和执行操作，并使用分配给该帐户的特权。
资源可以假设的虚拟角色是IAM角色。例如，EC2实例可以扮演角色并执行AWS命令，并具有分配的特权。API Gateway，Lambda，Kinesis，RDS等其他服务也是如此。
当他们说IAM角色无法直接要求AWS服务时，这是什么意思？
角色本身无法执行任何任务，因为必须由某人或某物承担。有人也可以通过身份联合会登录，然后扮演角色。
我实际上是AWS的新手，但我在后端应用程序中实现了类似的概念。因此，我将尝试从新手角度简化这一点。
- IAM用户 - 这是一个注册到AWS IAM平台的实际帐户。这意味着这是一个实际实体的人/应用程序。请注意，该实体无能为力，只是存在。就像我注册应用程序时一样，我的用户实体是创建的，我可以登录提供的凭据并具有个人资料。
-
IAM组 - 这是
collection of specific users。尽管这也可以给出身份，但重点放在成为团队的特定个人上。例如，我们如何根据其特定专业和技能组将员工分为组织的部门。 - IAM策略 - 这部分似乎最容易理解。这是以JSON格式以清晰的DOS和NOTS列出的对资源的特定规则/权限/访问。每个政策都是关于特定资源的。资源可以是EBS卷，LAMDA功能甚至IAM本身的任何内容。
-
IAM角色 - 这就像具有特定职责的
title，即任何具有此标题的人都有的一组策略（权限/访问）。例如，如果我们有"注释者"标题，则可以将来自不同部门的任何人临时分配给会议，期间等，并且只有获得此许可的人才能访问笔记应用程序。但是，我们可以扮演一些与小组相吻合的角色，例如会计部门的所有成员都可以拥有会计师的所有权，该会计师可以访问帐户。但是我们可以拥有另一个可以访问删除帐户的董事头衔，这将在所有部门中削减。 -
联合用户 - 这些也是实体，但公司（IAM）中没有个人资料。他们就像承包商一样，可以通过联合平台获得的收购信任以及由于这些标题而获得的访问权限，可以分配某些角色或
titles。好事是，如果联合平台替换了用户，则没有理由停用旧用户并访问新用户，因为该平台是具有访问权限的平台，而不是"用户"。
iam用户 - 用户/应用程序访问AWS资源IAM角色 - 可以适用于用户或资源的权限/策略集。
您也可以将角色应用于IAM用户和AWS资源。例如，将IAM角色应用于lambda功能。函数只能使用该IAM角色。
iam角色是一个实体，具有由策略定义的特定访问权限。那是。它具有永久性信用（访问密钥和秘密访问密钥） - 它可以在" asherole"上使用。授予令牌访问不同AWS资源的方法。
iam用户具有永久访问键和秘密访问密钥，我们可以定义资源的权限，IAM角色可以由IAM用户承担，因为它具有键 - 它可以一直访问资源...
IAM策略（ permissions-读取，写作等）适用于用户，组和角色。
用户 - 当用户想访问AWS Cloud中的任何内容时，它必须分配IAM策略。
group - 当一组用户分配了通用IAM策略时。
角色 - 当服务要访问另一个服务时，它需要。必须分配服务的角色，这些角色具有为在AWS云中执行某些操作的策略。换句话说，我们不能直接分配服务的策略，首先我们需要创建角色，然后分配该角色的策略。
注意：角色旨在不使用身体人员使用，而仅由AWS服务使用。