EKS Pod Identity 实现云资源鉴权需先确保集群启用 OIDC 提供者且服务账户正确绑定 IAM 角色，否则将触发 WebIdentityErr 或 NoCredentialProviders 错误；1.23+ 集群须验证 oidc.issuer 非空及 pod-identity-webhook 存在；服务账户须通过 eks.amazonaws.com/role-arn 注解关联具备 sts:AssumeRoleWithWebIdentity 权限的角色，其信任策略需精确匹配 OIDC Issuer 与 serviceaccount namespace/name；Pod 内 SDK 默认支持凭证链，但需 automountServiceAccountToken:true、/var/run/secrets/eks.amazonaws.com/serviceaccount/token 可读，且不可设置 AWS_ACCESS_KEY_ID 等静态密钥环境变量；权限变更后旧 Pod 不自动刷新凭证，必须重建 Pod 才生效。
直接用 EKS Pod Identity 实现云资源鉴权，前提是你的 EKS 集群已启用 OIDC 提供者且服务账户已正确绑定 IAM 角色——否则所有后续操作都会卡在 WebIdentityErr: failed to retrieve credentials 或 SDK 报错 NoCredentialProviders。
确认集群是否支持 EKS Pod Identity
不是所有 EKS 版本都默认开启该功能。1.23+ 集群需确保以下两点已就绪：
-
aws eks describe-cluster --name <cluster-name> --query "cluster.identity.oidc.issuer"</cluster-name>返回非空值（如https://oidc.eks.<region>.amazonaws.com/id/ABCD1234567890</region>） -
kubectl get mutatingwebhookconfigurations | grep pod-identity应输出pod-identity-webhook（这是 EKS 自动部署的组件，非手动安装） - 若使用
ack-pod-identity-webhook（阿里云 ACK 场景），则需额外验证其是否处于Ready状态：kubectl get pods -n ack-system | grep pod-identity-webhook
缺失任一条件，AssumeRoleWithWebIdentity 流程无法启动，SDK 就不会尝试从 /var/run/secrets/eks.amazonaws.com/serviceaccount/token 读取 JWT。
创建带 IAM 角色绑定的服务账户
服务账户本身不带权限，必须通过 Annotations 显式关联一个具备 sts:AssumeRoleWithWebIdentity 权限的 IAM 角色。关键点在于注解格式和角色信任策略：
- 服务账户 YAML 中必须包含：
eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-pod-role - 对应 IAM 角色的信任策略中，
Condition必须精确匹配你的 OIDC Issuer 和 service account namespace/name，例如："sub": "system:serviceaccount:default:my-app" - 不要复用节点角色（
NodeInstanceRole），否则容器可能意外获取更高权限；也不要省略namespace——default:my-app和prod:my-app是两个完全独立的信任主体
错误示例：eks.amazonaws.com/role-arn 指向一个未配置 Web Identity 信任策略的角色，会导致 Pod 启动后日志持续刷出 Failed to refresh credentials，但容器进程不会崩溃，容易误判为逻辑正常。
Pod 内应用如何正确使用 AWS SDK
AWS SDK（v2+）默认启用凭证链自动发现，无需改代码，但必须满足运行时环境约束：
- Pod 必须挂载服务账户令牌：
automountServiceAccountToken: true（默认为true，但若所在命名空间或 SA 显式设为false，则需手动修复） - 确保容器内路径
/var/run/secrets/eks.amazonaws.com/serviceaccount/token可读（非 root 用户需有 read 权限） - 避免设置
AWS_ACCESS_KEY_ID等环境变量——一旦存在，SDK 会跳过 Web Identity 流程，直接尝试使用静态密钥，导致权限与预期不符 - 调试时可用
aws sts get-caller-identity --endpoint https://sts.<region>.amazonaws.com</region>验证当前有效身份（注意：需在容器内执行，且 CLI 版本 ≥ 2.13.0）
常见陷阱是本地开发时用 ~/.aws/credentials 跑通了，上集群后因环境变量残留或镜像内硬编码密钥，绕过了 Pod Identity，造成权限测试失效。
权限变更后凭据不会热更新
服务账户注解或 IAM 角色策略修改后，已有 Pod 不会自动刷新凭证——JWT 有效期默认 10 小时，且 SDK 缓存凭据直到过期或主动触发刷新。这意味着：
- 加权限？必须重建 Pod（
kubectl delete pod或滚动更新 Deployment） - 删权限？旧 Pod 仍可继续调用，直到 token 过期或容器重启
- 没有类似
kubectl rollout restart的“重载权限”命令，一切依赖 Pod 生命周期
这点和传统节点级 IAM 角色完全不同，也是最容易被忽略的运维盲区：你以为权限已回收，其实 Pod 还拿着旧 token 在跑。
