问题

在AWS中“假设”一个角色到底意味着什么？提供了明确的定义？

假设经常使用角色并尝试理解定义及其实际含义。

我认为当一个主体（IAM用户，在EC2实例中运行的应用程序等调用访问AWS资源的操作）需要调用访问AWS资源的操作时：

当第3步发生时，就说“委托人承担了这个角色”。这是对的吗？

研究

在IAM用户，应用程序或服务可以使用您创建的角色之前，您必须授予切换到该角色的权限。您可以使用附加到IAM用户组之一或用户自身的任何策略来授予必要的权限。

答案 0 :(得分：14)

假设某个角色意味着要求安全令牌服务（STS）为您提供一组临时凭据 - 角色凭据 - 特定于您要承担的角色。（具体来说，是一个具有该角色的新“会话”。）

您可以选择包含一个包含此请求的策略，该策略将用于将临时凭证的权限仅限制为角色策略允许的子集。

然后，您可以使用这些凭据进行进一步的请求。这些凭据看起来类似于具有access-key-id和secret的IAM用户凭证，但访问密钥以ASIA而不是AKIA开头，并且还有第三个元素，称为安全令牌，必须是包含在使用临时凭证签名的请求中。

当您使用这些临时凭证发出请求时，您拥有与该角色关联的权限，而不是您自己的权限（如果您有），因为您已经使用了新身份。 CloudTrail可用于将角色凭证追溯回承担该角色的用户，但该服务不知道谁在使用该凭证。

tl; dr：假设某个角色意味着获取一组与该角色相关联的临时凭证，而不是与承担该角色的实体相关联。

AWS（API？或AWS中的某些授权运行时？）标识可以授予主体的角色。

没有。您可以指定要承担的角色。

当“你”是在EC2实例上运行的代码，并且实例具有实例角色时，EC2基础结构实际上代表实例调用了assume-role，并且您可以从{{3}获取临时凭证}。这些凭据只能从实例中访问，但它们不存储在实例中。

运行Lambda函数时，Lambda基础结构会联系STS并将您的临时凭据放在instance metadata service中。同样，函数可以访问这些凭据，而不会存储在函数内。

在任何一种情况下，您都可以使用这些凭据调用assume角色并承担不同的角色，但在大多数环境中这不是必需的。

e.g。如果指定EC2用户执行assume-role API调用并运行访问IAM配置文件所附加的EC2实例中的AWS资源的应用程序，则：

AWS无法了解EC2 用户。实例上运行的所有内容都可以访问实例角色。

EC2 IAM配置文件中的所有IAM角色

假设角色调用中请求的IAM角色和策略

您要求只承担一个角色。您无需请求策略 - 如果您希望临时凭证具有更少的特权，而您只需要角色凭据允许，则只需指定策略。如果您需要在不受信任的地方运行代码（例如浏览器或应用程序中的代码），您可以执行此操作，以便能够使用凭据对请求进行签名。

AWS从角色中找到角色，该角色具有允许原则对资源执行操作的策略（操作，资源）。

没有。如上所述，当您调用assume-role时，您会要求具体的角色。

AWS将原则的角色转换为已识别的角色。

没有。您使用提供的临时凭证进行切换。

答案 1 :(得分：3)

我为自己创建了以下图表，以了解在AWS中确切扮演什么角色。希望对您有所帮助。

在图中，我将其分为三个步骤：

答案 2 :(得分：1)

当第3步发生时，据说：＆＃34;委托人已经承担了角色＆＃34 ;.这是对的吗？

您在承担角色时提到的步骤正确。

重要的一点是IAM角色的信任关系配置，您可以授予每个IAM用户，应用程序或服务担任该角色的权限。这是您授予承担特定角色的权限的地方。

这在许多方面都很重要，它控制着谁可以担任这个角色，并且重要的是不仅要提供对该角色的最少访问权限，而且还要授予可以担任该角色的实体数量最少的实体。