使用根用户运行预定义CloudFormation栈时遭遇sts:AssumeRole权限错误的解决方案咨询

Hey，我看你在部署AWS电信网络的CloudFormation栈时碰到了sts:AssumeRole权限拒绝对吧？而且还是用根用户操作的情况，这确实有点让人头疼，我来给你梳理几个排查和解决的方向：

• 先锁定目标角色，检查它的信任策略
  你得先从完整的CloudTrail事件里找到CloudFormation试图扮演的那个IAM角色ARN（一般在requestParameters字段的roleArn值里）。找到这个角色后，重点看它的信任策略——这是控制谁能扮演该角色的核心：

  • 要么你的根用户ARN（也就是arn:aws:iam::x:root）被明确允许在这个角色的信任策略里执行sts:AssumeRole；
  • 要么因为是CloudFormation服务触发的调用，信任策略里要把cloudformation.amazonaws.com设为可信主体，这样CloudFormation才能代表你的根用户去扮演这个角色。
    给你举个允许CloudFormation服务的信任策略示例：

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": {
          "Service": "cloudformation.amazonaws.com"
        },
        "Action": "sts:AssumeRole"
      }
    ]
  }
  

  另外提一句，你的根用户没启用MFA，虽然根用户默认权限最大，但如果目标角色的信任策略里强制要求MFA认证，那也会触发报错，这个可以顺便排查下。

• 排查账号级别的SCP限制
  虽然根用户默认不受IAM权限边界约束，但如果你的AWS账号属于某个Organizations组织，组织里的服务控制策略（SCP）可能会限制sts:AssumeRole动作。去Organizations控制台看看有没有SCP包含拒绝sts:AssumeRole的规则，或者只允许扮演特定角色的限制，要是有的话得调整SCP来放行目标角色的扮演操作。

• 确认CloudFormation执行角色的配置
  如果你在创建栈的时候指定了CloudFormation的“执行角色”，那这个执行角色本身得有sts:AssumeRole权限去调用目标角色。不过你是用根用户运行的栈，大概率没指定这个角色，这时候CloudFormation会用根用户的权限去尝试扮演目标角色，但核心还是回到目标角色的信任策略是否允许。

• 把CloudTrail事件看完整
  你贴的事件内容不全，requestParameters和errorCode字段里肯定还有更详细的信息，比如具体是哪个角色无法被扮演，或者拒绝的具体原因。把这些信息挖出来，能更精准地定位问题——比如如果是信任策略不匹配导致的AccessDenied，直接改信任策略就行；如果是SCP限制，就去调整SCP。

备注：内容来源于stack exchange，提问作者Hem