IAM用户跨账号调用sts:AssumeRole报AccessDenied错误排查

该报错由account2侧角色roleTester的信任关系配置异常导致，account1侧IAM用户auditor的内联策略配置不存在权限不足的问题。

1. account1侧权限校验 #

auditor用户绑定的内联策略存在两条Allow规则：

• 第一条规则允许对本账号arn:aws:iam::account1:role/AuditorCheck角色执行全量STS操作
• 第二条规则允许对*（所有资源）执行全量STS操作

IAM授权逻辑默认取所有Allow规则的并集，无显式Deny规则时即放行对应操作，因此auditor用户本身完全具备对account2侧roleTester发起sts:AssumeRole调用的权限，这部分配置无问题。
另外你的Java代码逻辑不存在参数错误：传入的角色ARN、ExternalId、角色会话名均符合要求，代码中未被使用的EnvironmentVariableCredentialsProvider实例不会影响STS客户端的凭证加载逻辑。

2. account2侧信任策略问题 #

你当前配置的roleTester信任策略使用了过时的2008-10-17版本策略语法，该版本语法在处理「跨账号根用户作为Principal+ExternalId字符串匹配」的场景时存在逻辑缺陷：无法正确匹配账号下普通IAM用户发起的带ExternalId的AssumeRole请求，仅会放行目标账号根用户直接发起的请求，因此直接返回AccessDenied错误。

将account2侧roleTester的信任策略版本修改为当前通用的2012-10-17即可，修正后的策略如下：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::account1:root"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "sts:ExternalId": "d5d2c143-f6b4-48e9-bd16-8708d86a0152"
                }
            }
        }
    ]
}

如果修改后仍报错，可额外校验account2侧是否存在组织SCP、角色权限边界规则拒绝了该次AssumeRole请求，从当前报错信息判断，核心诱因就是信任策略版本过低导致的条件匹配失效。

内容的提问来源于stack exchange，提问作者Ihsan Haikal