同一ServiceAccount下Airflow创建Pod正常，Helm部署Pod出现IAM AccessDenied如何排查

• 静态凭证优先级高于IRSA凭证：Helm部署的Pod被注入了AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY这类静态凭证环境变量，AWS SDK会优先使用静态凭证，导致实际未使用绑定的IAM角色
• IRSA必要环境变量被篡改：Helm部署配置中覆盖了AWS_ROLE_ARN、AWS_WEB_IDENTITY_TOKEN_FILE两个IRSA依赖的环境变量，导致SDK无法正确获取角色凭证
• IAM权限策略存在条件限制：MyCustomRole的权限策略中针对dynamodb:CreateTable操作设置了条件限制，比如限制表名前缀、会话名称、请求来源等，Airflow Pod的运行参数符合条件，而Helm部署的Pod触发了限制规则
• 角色凭证未更新：修改IAM权限后未重启Helm部署的Pod，Pod内缓存的是旧版本无权限的临时凭证
• Web Identity Token读取权限不足：Deployment配置的securityContext.runAsUser指定的用户无权限读取IRSA挂载的token文件，导致SDK fallback到节点实例角色，而实例角色无DynamoDB权限

1. 检查Pod环境变量：执行kubectl exec -it <Helm部署的Pod名称> -n <命名空间> -- env | grep AWS，确认是否存在静态AKSK相关变量，同时确认AWS_ROLE_ARN值为arn:aws:iam::1234567890:role/MyCustomRole、AWS_WEB_IDENTITY_TOKEN_FILE值为/var/run/secrets/eks.amazonaws.com/serviceaccount/token
2. 验证实际使用的身份：如果镜像中预装了awscli，执行kubectl exec -it <Helm部署的Pod名称> -n <命名空间> -- aws sts get-caller-identity，确认返回的ARN和错误日志中的assumed-role一致，排除使用其他身份的可能
3. 核对IAM权限策略：检查MyCustomRole关联的权限策略，确认dynamodb:CreateTable对应的资源ARN包含你要创建的DynamoDB表，同时没有设置不匹配的条件限制
4. 验证token文件可访问：执行kubectl exec -it <Helm部署的Pod名称> -n <命名空间> -- cat /var/run/secrets/eks.amazonaws.com/serviceaccount/token，确认可以正常读取token内容
5. 重启Pod刷新凭证：执行kubectl rollout restart deployment <Helm部署的Deployment名称> -n <命名空间>，重启后重试操作排除旧凭证缓存问题
6. 对比两个Pod的差异：执行kubectl get pod <Airflow创建的Pod名称> -o yaml和kubectl get pod <Helm部署的Pod名称> -o yaml，对比所有env、securityContext、volumeMounts配置的差异，排除配置遗漏

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