通过AWS CLI执行assume-role时ARN被附加botocore-session-id的原因是什么

核心疑问答复 #

你判断的触发原因完全正确：当前会话已经处于目标角色的扮演状态，而该IAM角色本身没有被授予调用sts:AssumeRole访问自身的权限，因此重复扮演同一角色时触发了AccessDenied报错。

缓存清理无效的原因 #

AWS CLI底层基于botocore库实现凭证管理，除了~/.aws/cache目录外，临时凭证还可能存在于两个优先级更高的位置，你之前的清理操作没有覆盖到：

• 当前Shell会话的环境变量：AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、AWS_SESSION_TOKEN三个环境变量的优先级高于本地配置文件，即使重启iTerm如果复用了会话环境也会残留凭证
• ~/.aws/credentials配置文件：如果之前的assume-role操作将临时凭证写入了对应profile的配置块，清理缓存目录不会影响该文件的内容

修复步骤 #

按以下顺序操作即可解决问题：

1. 清空当前Shell的AWS相关环境变量，执行命令：
   unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN AWS_PROFILE
2. 打开~/.aws/credentials文件，找到你使用的<the_profile_name>对应的配置块，删除块内aws_access_key_id、aws_secret_access_key、aws_session_token三个临时凭证字段，仅保留role_arn、source_profile等基础配置即可
3. 执行以下命令验证当前身份已恢复为源身份：
   aws sts get-caller-identity --profile <the_profile_name>
   如果返回的ARN为你的原始IAM用户/角色ARN（不带assumed-role和botocore-session前缀），即可重新执行原assume-role命令正常获取凭证。

可选优化（不推荐） #

如果需要允许重复扮演同一角色，可以在目标IAM角色的权限策略中添加允许自身调用sts:AssumeRole的规则，但该配置会扩大权限面，存在安全风险，不建议生产环境使用。

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