为何aws sts get-caller-identity在Ansible与手动执行时结果不同？

开发者阿泽

2026-8-14

问题描述

在Jenkins任务中运行Ansible playbook执行以下任务：

- name: printing get caller
  shell: "aws sts get-caller-identity"
  register: var_caller

- debug:
    msg: "{{var_caller.stdout}}"

返回结果为：

ok: [local-server] => {
    "msg": {
        "Account": "8693XXXXXX",
        "Arn": "arn:aws:iam::8693XXXXXX:user/user-A",
        "UserId": "AIDAJEXXXXXXXXXX"
    }
}

但在同一EC2实例local-server上手动执行aws sts get-caller-identity命令时，返回的是扮演角色的结果，账号ID也不同：

[root@local-server] aws sts get-caller-identity
{
    "UserId": "AROAZXXXXXXXX:i-01143d8XXXXXXX",
    "Account": "653XXXXXXX",
    "Arn": "arn:aws:sts::653XXXXXXX:assumed-role/role-A/i-01143d8XXXXXXX"
}

注：未使用任何手动配置的AWS凭证，EC2实例local-server已绑定IAM角色role-A。两者本应返回相同结果，请问可能存在哪些配置问题？

可能的配置问题

Jenkins进程继承了优先级更高的AWS凭证：Jenkins服务启动时可能加载了来自环境变量（AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY）、Jenkins全局凭证插件配置的user-A凭证，或是Jenkins运行用户的~/.aws/credentials文件内容，这些凭证优先级高于EC2实例的IAM角色临时凭证。
Ansible执行时被注入了额外AWS配置：检查Ansible playbook的environment模块、Jenkins任务传递的额外变量（extra_vars），或是ansible.cfg配置文件，是否设置了AWS相关环境变量，覆盖了实例的IAM角色凭证。
EC2元数据服务访问异常：Ansible执行shell模块时，可能因进程网络限制、权限问题无法访问EC2元数据服务（http://169.254.169.254/latest/meta-data/），导致无法获取IAM角色临时凭证，转而使用其他来源的凭证。可在Ansible任务中添加测试命令curl http://169.254.169.254/latest/meta-data/iam/security-credentials/，验证元数据访问是否正常。
Jenkins运行用户与手动执行用户环境不同：手动执行用的是root用户，而Jenkins通常以jenkins用户运行，两个用户的环境变量、AWS配置文件路径存在差异。检查jenkins用户的~/.aws目录下是否存在配置文件，或其环境变量中是否有AWS相关配置。
AWS CLI配置文件优先级生效：即使未手动配置，Jenkins部署过程中可能自动生成了jenkins用户的~/.aws/config或~/.aws/credentials文件，其中的默认凭证会优先于实例IAM角色生效。

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