ICYMI，2022 年 9 月 21 日，AWS宣布他们正在改变在担任角色时如何评估信任策略的一个方面。虽然我们强烈建议您阅读整个公告，因为其中包含有关变更的宝贵信息，但我们认为让社区快速了解究竟发生了什么以及此变更可能对您意味着什么会很有用。
有什么变化？
过去，IAM 角色隐含地信任自己；也就是说，如果他们附加了允许他们这样做的 IAM（基于身份）策略，他们可以假设自己。这与所有其他 IAM 角色的处理方式不同，因为它们必须包含在角色的信任关系中。
举一个 AWS 公告中的例子，如果我们在账户 123456789012 中有一个名为 RoleA 的角色，那么下面的信任关系策略是允许 RoleB 代入 RoleA 所必需的：
{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Principal": {"AWS": "arn:aws:iam::123456789012:role/RoleB"},"Action": "sts:AssumeRole"}]}
{"Version": "2012-10-17","Statement": {"Effect": "Allow","Action": "sts:AssumeRole","Resource": "arn:aws:iam::123456789012:role/RoleA"}}
{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Principal": {"AWS": ["arn:aws:iam::123456789012:role/RoleB","arn:aws:iam::123456789012:role/RoleA"]},"Action": "sts:AssumeRole"}]}
如果您最近（在 2022 年 6 月 30 日和 2022 年 9 月 21 日之间）有一个 IAM 角色，该角色在没有明确信任的情况下假设自己，则隐含的自我信任将继续适用，直到 2023 年 2 月 15 日。
但是对于任何新角色或者没有假设自己的角色，您现在将体验到新的行为——也就是说，如果没有明确的信任，角色将无法假设自己——因此您必须在角色的信任策略中添加明确的信任。
为什么会发生变化？
一言以蔽之——一致性；一个 IAM 角色的自我假设被视为与任何其他 IAM 角色的假设相同，这很有意义。这种统一性是一个值得欢迎的变化——通过消除这个隐藏的警告，它使理解 AWS IAM 使用的评估逻辑的实践更加直接。
等同于第一个示例，“pod-viewer”角色可以在多个命名空间之间重复使用。现在有一个集中的地方来管理一组通用权限，这些权限可以在广泛的命名空间中使用，而无需授予用户对所有命名空间的访问权限。
它对你有什么影响？
如果您的 IAM 角色在其操作中依赖于自我假设，并且当前没有明确将自己包含在信任关系策略中，那么他们可能已经被拒绝访问假设自己（请参阅“发生了什么变化？”）。
虽然这种行为极为罕见（根据公告，只有大约 0.0001% 的所有 IAM 角色使用它），但它可能会在您的部署中的某个地方使用。不处理此问题可能会导致您的基础架构意外（并且有些难以调试）服务中断——因此您应该意识到这一点。
你应该怎么办？
与许多问题一样，获得控制权的第一步是获得适当的可见性，以了解使用这种行为的位置。我们应该提到，在公告中，亚马逊表示它已经开始通知客户在他们的账户中有这种行为。
执行此操作的最佳方法可能是查找会话颁发者 ARN 与执行假设角色的 IAM 角色的 ARN 相同的假设角色事件。AWS 的公告提供了一些很好的示例，说明如何使用 Athena 和/或 CloudTrail Lake 做到这一点。
您还可以使用我们利用 AWS 的 CLI 编写的以下脚本（请注意，您应该修改开始和结束时间，并指定 CLI 使用的配置文件）：
( echo "Time,Identity ARN,Event ID, Session ARN";aws cloudtrail --region us-east-2 --profile <CLI_PROFILE_NAME> lookup-events --start-time "2022-10-01T13:00:00Z" --end-time "2022-10-02T13:00:00Z"--lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRole --query "Events[*].CloudTrailEvent"--output text| jq -r ". | select(.eventSource == "sts.amazonaws.com" and .eventType == "AwsApiCall" and .errorCode == nulland .eventName == "AssumeRole" and .userIdentity.type == "AssumedRole"and .userIdentity.sessionContext.sessionIssuer.arn[12:] == .resources[].ARN[12:])| [.eventTime, .userIdentity.arn, .eventID, .userIdentity.sessionContext.sessionIssuer.arn] | @csv") | column -t -s'",'
要运行此命令，您需要在相关账户中拥有有权获得cloudtrail:LookupEvents权限的委托人。您可以使用此 IAM 权限策略来授予它：
{"Version": "2012-10-17","Statement": [{"Sid": "lookupevents","Effect": "Allow","Action": "cloudtrail:LookupEvents","Resource": "*"}]}
一旦你找到了所有相关的事件，你就需要决定你的策略是什么。
最简单的当然是在其信任策略中为 IAM 角色添加显式信任。这将保持其假设自己的能力。
但是，在IAM角色上使用自我假设通常不是推荐的方法，它的使用实际上表明错误使用了 AWS 资源（IAM 角色信任更新公告中详细列出了一个非常详细的列表）。实际上，对于这种行为有意义的情况很少。公告中提到的几个此类用例是使用会话策略“缩小”权限（即，针对不同场景使用具有不同权限的 IAM 角色）并在生产和开发中使用相同的代码承担目标计算角色——甚至这两个用例也推荐了替代品。
总之，我们强烈建议您借此机会重新考虑使用自我假设的方法，并将其任何实例替换为可行的、更好的实践替代方案。
【火线Zone云安全社区群】
进群可以与技术大佬互相交流
进群有机会免费领取节假日礼品
进群可以免费观看技术分享直播
识别二维码回复【社区群】进群
火线Zone是[火线安全平台]运营的云安全社区，内容涵盖云计算、云安全、漏洞分析、攻防等热门主题，研究讨论云安全相关技术，助力所有云上用户实现全面的安全防护。欢迎具备分享和探索精神的云上用户加入火线Zone社区，共建一个云安全优质社区！
如需转载火线Zone公众号内的文章请联系火线小助手：hxanquan（微信）
// 火线Zone //
微信号 : huoxian_zone
点击阅读原文，加入社区，共建一个有技术氛围的优质社区！
原文始发于微信公众号（火线Zone）：您需要知道的IAM 角色信任更新
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论