Bash脚本中AWS凭证变量传递为空问题排查

• 环境变量不继承：sudo su切换用户时，默认不会继承原用户的完整环境变量（比如AWS_CONFIG_FILE、AWS_PROFILE等），而手动执行时是在当前用户的正常环境下运行。脚本中切换用户后执行aws sts assume-role，可能因为缺少必要的AWS配置环境变量，导致命令未正确生成凭证，/awsCredential文件内容为空或格式异常，后续jq自然无法解析出AccessKeyId。

• 文件权限不足：sudo su切换到目标用户后，该用户可能没有/awsCredential文件的写入权限（比如文件属于其他用户且未开放写入权限），导致凭证内容实际未写入成功。手动执行时你使用的用户拥有足够权限，所以能正常写入文件。可以用ls -l /awsCredential查看文件的所有者和权限配置。

• 命令执行的引号转义问题：如果脚本中是通过sudo su - user -c "aws sts assume-role ... > /awsCredential"这种方式执行命令，要注意命令内的引号转义。比如角色ARN包含特殊字符时，未正确转义会导致命令执行失败，生成的文件内容不是预期的JSON格式，jq解析时自然返回空值。而手动交互式执行时不会遇到这个问题。

• jq依赖缺失：切换到目标用户后，该用户的PATH中没有jq命令，或者系统未安装jq，导致$(cat /awsCredential | jq -r '.Credentials.AccessKeyId')执行失败，返回空值。手动执行时你使用的用户环境中存在jq，所以能正常解析JSON。可以在脚本切换用户后先执行which jq确认是否存在该命令。

• assume-role命令执行失败未检测：脚本中执行aws sts assume-role时未检查命令返回值，可能该命令因权限不足（目标用户无assume对应角色的权限）、角色ARN错误等原因执行失败，输出了错误信息而非预期的JSON到文件中，导致jq无法解析出Credentials字段。手动执行时你可能在交互式环境中看到错误并修正，或者当前用户拥有足够权限。可以直接查看/awsCredential文件的内容，确认是否是错误信息而非合法JSON。

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