Vault外部认证权限拒绝求助：K8s对接EC2上的Vault HA集群

本地环境正常、AWS部署环境出错，核心差异点集中在集群配置、认证绑定、网络或权限规则上，按以下步骤逐一验证：

1. 核对Kubernetes Auth后端配置 #

• 检查Vault上K8s auth后端的集群地址和CA证书是否指向AWS K8s集群的正确值：

  vault read auth/kubernetes/config
  

  重点确认kubernetes_host（如EKS的API服务器地址）和kubernetes_ca_cert（需从AWS K8s集群的/var/run/secrets/kubernetes.io/serviceaccount/ca.crt获取并导入Vault），避免误用本地K8s的配置。

2. 验证角色与ServiceAccount的绑定匹配 #

• 检查Vault角色的绑定规则，确保ServiceAccount名称和命名空间与应用部署环境完全一致（大小写敏感）：

  vault read auth/kubernetes/role/[你的角色名]
  

  确认bound_service_account_names和bound_service_account_namespaces字段与应用所在的ServiceAccount、命名空间严格对应。

3. 检查策略的路径与权限 #

• 验证角色关联的策略是否包含应用需访问密钥路径的read权限：

  vault policy read [你的策略名]
  

  例如应用读取KV v2密钥时，策略需正确配置路径：

  path "secret/data/myapp/*" {
    capabilities = ["read"]
  }
  

  注意区分KV v1（路径为secret/xxx）和KV v2的路径格式。

4. 模拟Sidecar认证流程测试 #

• 在K8s应用的命名空间内启动测试Pod，模拟Sidecar的认证过程：

  kubectl run test-vault-auth --rm -it --image=alpine --serviceaccount=[应用ServiceAccount名] -- sh
  

  在Pod内执行认证请求：

  apk add curl
  TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
  curl -X POST -H "Content-Type: application/json" -d '{"jwt": "'$TOKEN'", "role": "[你的角色名]"}' https://[Vault地址]/v1/auth/kubernetes/login
  

  • 若返回permission denied：认证环节失败，回到步骤1-2排查配置
  • 若返回含client_token的结果：认证正常，问题出在策略权限或密钥路径

5. 确认网络连通性 #

• 检查K8s Pod能否访问Vault HA集群，无安全组、NACL或防火墙拦截：

  telnet [Vault地址] 8200
  

  若不通，检查EC2安全组是否允许K8s集群CIDR访问8200端口；若使用负载均衡，确认LB能正确路由到Vault主节点。

6. 检查Vault HA集群状态 #

• 确认Vault集群主节点正常，未处于密封状态：

  vault status
  

  若集群处于密封状态需先unseal；若主节点切换，确认Sidecar配置的Vault地址指向正确的主节点或负载均衡器。

7. 核对Sidecar注解配置 #

• 确认应用Pod的注解中，Vault角色名、密钥路径与配置完全匹配：

  annotations:
    vault.hashicorp.com/role: "[你的角色名]"
    vault.hashicorp.com/agent-inject: "true"
    vault.hashicorp.com/agent-inject-secret-db: "secret/data/myapp/db"
  

  确保路径与策略配置一致，角色名无拼写错误。

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