AWS跨账户角色扮演（AssumeRole）失败的完整排查与修复指南

本文详解跨账户 IAM 角色扮演失败的核心原因——信任策略（Trust Policy）中 Principal 配置错误，并提供可落地的策略修正、代码验证及安全实践建议。

在 AWS 的多账户架构里，通过 STS 的 `AssumeRole` 来实现跨账户权限委派，是一种既常见又安全的设计模式。但很多开发者在实践中都会踩到一个“坑”：明明两边账户的权限策略看起来都配置对了，可一执行调用，返回的永远是那个令人头疼的 403 AccessDenied 错误。

比如，错误信息可能长这样：

User: arn:aws:sts:::assumed-role//... is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam:::role/my-query-role

看到这个错误，第一反应往往是去检查发起调用的账户（Account 1）有没有 `sts:AssumeRole` 的权限。但真相是，问题通常不出在这里。真正的症结，在于目标账户（Account 2）里，那个你试图扮演的角色 `my-query-role`，它的“信任策略”并没有认出你是谁。

简单来说，不是你“没有权力去扮演”，而是对方“根本不信任你，不让你扮演”。

关键原理：信任必须精确匹配“实际调用者”ARN

这里有个关键细节容易被忽略。当你通过类似 WebIdentityTokenFileCredentialsProvider（常见于 EKS Pod 的 IAM Roles for Service Accounts 场景）这类方式拿到临时凭证后，再去调用 `AssumeRole`，你的身份其实已经发生了一次转换。

此时，实际发起请求的主体，已经不是最初的 IAM 角色 ARN 了，而是 STS 服务动态生成的一个 assumed-role ARN。它的格式是这样的：
arn:aws:sts:::assumed-role//

回过头来看一个典型的错误配置。很多人在目标角色的信任策略里会这么写：

"Principal": { "AWS": ["arn:aws:iam:::root"] }

这个配置的意思是：“我允许 Account 1 的根账户（也就是整个账户）来扮演我。” 但它并不包含该账户内任何一个 IAM 角色所派生的“会话身份”。AWS 的策略评估机制非常严格，它会逐字比对 Principal 字段。所以，`arn:aws:iam::123456789012:root` 和 `arn:aws:sts::123456789012:assumed-role/account-1-role/xyz` 会被判定为两个完全不同的身份，匹配失败，403 错误也就来了。

那么，正确的做法是什么？

答案是：在 Account 2 的目标角色 `my-query-role` 的信任策略中，必须明确列出 Account 1 中那个具体的、有资格发起扮演的 IAM 角色 ARN。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam:::role/account-1-role"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

⚠️ 这里有个重要提示：信任策略里填写的必须是 `arn:aws:iam::...:role/...` 这种原始角色 ARN 格式，而不是 `arn:aws:sts::...:assumed-role/...` 这种会话 ARN。AWS 在处理 `AssumeRole` 请求时，会自动将传入的 assumed-role ARN 映射回其源头的 IAM 角色，然后用这个源头角色去匹配信任策略里定义的 Principal。

验证与最佳实践

理解了核心问题，我们再来系统性地梳理一下整个流程，并看看如何加固安全。

1. 权限策略（Account 1）保持不变

发起方账户（Account 1）的权限策略通常不需要改动，只要它已经正确授权了对目标角色的 `sts:AssumeRole` 操作即可。下面是一个标准的配置示例：

{
  "Version": "2012-10-17",
  "Statement": [{
    "Action": "sts:AssumeRole",
    "Effect": "Allow",
    "Resource": "arn:aws:iam:::role/my-query-role"
  }]
}

2. Ja va SDK 调用逻辑无误

你的 Ja va 代码结构基本没问题，但有一个细节值得注意：`roleSessionName` 最好具备唯一性和可追溯性，便于后续审计。

AssumeRoleRequest assumeRoleRequest = AssumeRoleRequest.builder()
    .roleArn("arn:aws:iam:::role/my-query-role")
    .roleSessionName("cross-account-query-session-" + System.currentTimeMillis()) // 建议加入时间戳或唯一ID
    .build();

3. 进阶加固：限制信任范围

遵循最小权限原则，我们应该尽量避免使用过于宽泛的信任策略（比如信任整个根账户 `:root`）。更安全的做法是：

• 指定具体角色 ARN：如上文所述，这是最基本也是最重要的一步。
• 添加条件约束：通过 `Condition` 字段进一步收窄信任范围。例如，可以限制请求必须来自特定区域、特定 IP 地址，或者要求必须使用了 MFA。

  "Condition": {
    "StringEquals": {
      "aws:RequestedRegion": "eu-west-1"
    }
  }

4. 排查工具辅助

如果遇到复杂情况，可以借助 AWS 提供的工具来辅助排查：

• AWS IAM Policy Simulator：这是一个非常实用的工具。你可以模拟一次 `sts:AssumeRole` 请求，输入 assumed-role ARN 和目标角色 ARN，它能直观地告诉你策略评估是通过还是拒绝，以及原因是什么。
• CloudTrail 日志：确保 CloudTrail 已启用并记录相关事件。在日志中搜索 `AssumeRole` 事件，仔细查看 `errorMessage` 和 `userIdentity.arn` 字段，这能帮你精准定位拒绝的根本原因。

总结

跨账户 `AssumeRole` 调用失败，十有八九问题都出在目标角色的信任策略配置不当上。要彻底避免这个坑，请牢记下面三个核心要点：

? 信任策略定义“谁被允许来”：它必须精确匹配调用方的源身份（即原始的 IAM Role ARN）。

? 权限策略定义“谁能去调用”：它控制着发起方是否有权限去执行 `sts:AssumeRole` 这个 API 动作。

? assumed-role ARN 是临时会话标识：它是 STS 生成的临时身份凭证，不应该直接填写在信任策略的 Principal 字段里。

一旦修正了信任策略，变更会立即生效，通常无需重启服务或刷新凭证。这种“精确信任”与“最小权限”的结合，正是构建安全、清晰、可审计的 AWS 多账户环境的基石。