在AWS中，“Assume”一个角色到底是什么意思？

Question

问题

在AWS中，“假设”一个角色的确切含义是什么，官方提供了明确的定义吗？

背景

“假设一个角色”经常被使用，我想了解其定义以及实际意义。

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

AWS（API？还是AWS中的某个授权运行时？）识别了可以授予主体的角色。例如，如果指定一个EC2用户来执行assume-role API调用，并在附加了IAM配置文件的EC2实例中运行访问AWS资源的应用程序，则会发生以下情况：

- 所有来自EC2 IAM配置文件的IAM角色 - assume-role调用中请求的IAM角色和策略 - EC2用户被授予的IAM角色

AWS会从这些角色中找到具有允许主体对资源执行操作的策略（动作，资源）的角色。

AWS会将主体的角色切换为所识别的角色。

当发生第3步时，我们说“主体已经扮演了该角色”。这样说对吗？

研究

[使用IAM角色](link1)

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

• 假设角色
• AssumeRole
• 使用IAM角色
• 使用IAM角色授予在Amazon EC2实例上运行的应用程序的权限

---

更新

• 扮演角色

在AWS中扮演IAM角色涉及到权限的临时转移。通过扮演角色，实体可以使用授权的权限执行任务和利用资源，而不会对自己的权限进行任何永久性更改。

一旦扮演角色的会话令牌过期，实体的附加权限将被撤销。

- mon

Answer 1

假设担任一个角色意味着要求安全令牌服务（STS）提供一组临时凭证——角色凭证，这些凭证特定于您想要扮演的角色。（具体而言，是与该角色新建立的“会话”有关。）

您可以选择在此请求中包含策略，以将临时凭证的权限限制为仅部分允许角色策略的内容。

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

当您使用这些临时凭证进行请求时，您具有与角色相关联的权限，而不是自己的权限（如果有的话），因为您已经扮演了一个新的身份。CloudTrail可用于跟踪角色凭证返回到扮演角色的用户，但否则服务不知道谁正在使用凭证。

简而言之：假设一个角色意味着获取一组临时凭证，这些凭证与扮演角色的实体无关，而是与该角色相关联。

AWS（API？还是AWS中的某个授权运行时？）识别可以授予主体的角色吗？

不，您需要指定要扮演的角色。

当"你"是运行在EC2实例上的代码，并且该实例具有实例角色时，EC2基础架构实际上代表实例调用assume-role，你可以从实例元数据服务获取临时凭证。这些凭证仅可从实例内部访问，但不存储在实例上。

运行Lambda函数时，Lambda基础架构会联系STS并将您的临时凭证放入环境变量中。同样，这些凭证对于函数是可访问的，而无需在函数内部存储。

在任一情况下，您都可以使用这些凭证调用assume role并扮演不同的角色，但在大多数环境中不需要这样做。

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

AWS不知道EC2 用户。 实例角色对在实例上运行的所有内容都是可访问的。

来自EC2 IAM配置文件的所有IAM角色

一个实例配置文件只能包括一个角色。

在assume-role调用中请求的IAM角色和策略

你需要扮演一个角色，只需请求一个策略 -- 当临时凭证需要比角色凭证拥有更少的权限时，才需要指定策略。如果你需要在一个不受信任的地方运行代码（例如浏览器或应用程序中的代码）以便能够使用凭证签署请求，则可能需要这样做。

AWS从具有允许主体对资源执行操作的策略（动作，资源）的角色中找到一个角色。

不是的。如上所述，在调用 assume-role 时，请请求特定角色。

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

不是的。通过使用提供的临时凭证，您自己进行切换。

- Michael - sqlbot

---

当我将角色“X”附加到EC2实例时，EC2实例会“承担”该角色吗？然后，当我使用“ec2-user”进行“aws s3 cp…”请求时，“ec2-user”会使用EC2实例可用的凭据，因为它已经承担了角色X的结果？ - Sheel Pancholi

@SheelPancholi EC2 服务 扮演角色并使凭据可用于实例 -- 实例上的任何和所有操作系统用户都可以通过实例元数据服务访问角色凭据，如上所述。 - Michael - sqlbot

假设我有角色A和B。您能否告诉我，如果A扮演B的角色，相比于自己在A上设置所需权限（由B授予的权限），这样做有哪些“优势”？ - blahblah

@Tomasz 如果这两个角色都是您自己账户中的角色，那么很难找到使用它们的显而易见的原因。 - Michael - sqlbot

@programming_and_math 在编程和数学方面，我们通常会看到IAM 用户 A和IAM角色B，而不是IAM角色A和IAM角色B。其中IAM角色B授予了一些更高的权限，例如能够读取S3存储桶中的敏感日志。使用角色B而不是直接给用户A访问存储桶的价值在于，IAM用户凭据是长期的，而IAM角色/STS凭据是短期的。暴露STS凭据的风险较低。当假定角色B时，您还可以要求MFA，而IAM用户通常需要为日常使用提供MFA可能会很麻烦。 - jarmod

Answer 2

我为自己创建了以下图表，以便了解在AWS中扮演角色的确切含义。希望这对你也有所帮助。

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

1. 准备角色（ExecutionRole和AssumedRole）
2. 在A账户上创建Lambda函数（在您的情况下是EC2）
3. 执行Lambda函数。

该图表使用跨帐户作为示例，如果在同一帐户中，则不需要步骤1.3。

通常，您在您的帐户内或用于跨帐户访问时使用AssumeRole。 ... 与角色相同帐户中的用户无需显式权限即可扮演该角色。
来源：https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html

- Devs love ZenUML

Answer 3

当完成第三步时，会被称为“负责人已经担任了角色”，这样说是正确的吗？

你提到的角色承担步骤是正确的。

在这里，IAM角色的信任关系配置非常重要，它允许每个IAM用户、应用程序或服务承担角色。这是授权承担特定角色的权限所在的地方。

这在许多方面都很重要，因为它控制着谁可以承担该角色，并且不仅需要为角色提供最少的访问权限，还需要授权尽可能少的实体来承担该角色。

- Ashan