本文为翻译文章，原文链接：https://ermetic.com/blog/aws/iam-role-trust-update-what-you-need-to-know/

IAM Role Trust Update – What You Need to Know

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"
        }
    ]
}

过去，RoleA 可以假设自己，即使它没有包含在信任策略中，只要它附加了一个基于身份的策略允许它这样做，例如：

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::123456789012:role/RoleA"
  }
}

这已不再是这种情况。IAM 角色的隐式自信任已不复存在。如果您希望新的 IAM 角色能够自行承担，您应该明确信任并将该角色包含在其自己的信任关系中，如下所示：

{
    "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 使用的评估逻辑的实践更加直接。

它对你有什么影响？

如果您的 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 == null
    and .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 角色）并在生产和开发中使用相同的代码承担目标计算角色——甚至这两个用例也推荐了替代品。

总之，我们强烈建议您借此机会重新考虑使用自我假设的方法，并将其任何实例替换为可行的、更好的实践替代方案。

    说点什么吧...