计算工作负载的实例配置文件

EC2 上的应用程序通常需要调用 AWS API，但嵌入访问密钥非常危险。解决方案是通过实例配置文件为实例提供自己的身份，该配置文件会自动提供临时角色凭证。这是考试中最常考的模式之一，用于从工作负载中消除长期密钥。

实例配置文件是一个用于容纳 IAM 角色的容器，您可以将它附加到 EC2 实例。虽然从概念上看是分配角色，但 EC2 实际附加的是包含该角色的实例配置文件。在控制台中为 EC2 创建角色时，系统会自动创建一个同名的实例配置文件；使用 CLI 或 API 时，您可能需要显式创建它。

附加实例配置文件后，实例可以从 Instance Metadata Service (IMDS) 获取临时凭证。该服务是位于 169.254.169.254 的特殊链路本地端点。AWS SDK 和 CLI 会透明地获取并刷新这些凭证，因此应用程序代码完全不需要处理密钥。

凭证位于与角色名称关联的元数据路径下。SDK 会自动查询该路径，但了解它有助于排查实例为何拥有意外的权限。下面的命令会显示实例上暴露凭证的位置。

一个重要优势是，IMDS 凭证会在过期前很久自动轮换。您无需存储任何内容，也没有会永久泄露的密钥，更不必自行构建轮换流程。这就是 AWS 建议优先使用实例配置文件，而不是将静态密钥放在服务器上的任何方案的原因。

原始元数据服务（IMDSv1）可能被攻击者通过 SSRF（服务器端请求伪造）攻击滥用，从而窃取角色凭证。IMDSv2 要求先通过 PUT 请求获取会话令牌，这可以阻止大多数 SSRF 漏洞利用。考试要求您强制使用 IMDSv2，并且最好将跳数限制设置为 1，以防止容器访问该服务。

实例配置文件中的角色应遵循最小权限原则：只授予工作负载所需的具体操作和资源。权限范围过大的 EC2 角色很危险，因为实例一旦遭到入侵（包括通过 SSRF 入侵），这些权限就会全部暴露。应严格限定策略范围，并使用条件来限制影响范围。

如果您发现应用程序中硬编码了静态访问密钥，或实例上存在凭证文件，补救措施是附加实例配置文件并删除这些密钥。考试经常将此描述为修复一项发现：正确答案是移除长期密钥，并依靠 IMDS 提供的基于角色的凭证。

EC2 实例在同一时间只能有一个实例配置文件附加到它，因此也只能有一个角色。如果工作负载需要不同的权限集合，应设计不同的角色，并使用不同的实例；或者让应用程序根据需要通过 STS 承担其他角色，而不是不断扩大唯一附加角色的权限范围。

由于角色凭证会在 CloudTrail 中显示为由承担角色的会话执行的操作，因此您可以准确审计实例执行过的操作。如果实例遭到入侵，对其进行快照并检查该角色的会话在 CloudTrail 中的记录，就能发现攻击者访问了什么。严格限定角色范围，再结合 CloudTrail 的可见性，是安全且符合考试要求的组合。

要保护 EC2 访问：附加一个包含最小权限角色的实例配置文件，强制使用 IMDSv2，将元数据跳数限制设置为 1，并移除所有静态密钥。实例会从 IMDS 获取并自动轮换临时凭证，从而为计算资源提供安全身份，无需您管理任何密钥。

检查您对实例配置文件的了解程度。

实例配置文件封装 IAM 角色并将其附加到 EC2，通过实例元数据服务提供自动轮换的临时凭证。这样可以彻底移除静态密钥。强制使用 IMDSv2 并将跳数限制设置为 1，以阻止通过 SSRF 窃取凭证；使用最小权限限定角色范围，并在 CloudTrail 中审计其会话。