使用Kubernetes认证登录Vault遇Permission Denied问题求助

首先补上最关键的缺失步骤 #

你已经创建了ServiceAccount、Vault策略，但没有创建Kubernetes认证角色——这个角色是绑定K8s服务账户和Vault策略的核心环节，执行以下命令创建devweb-app角色：

vault write auth/kubernetes/role/devweb-app \
  bound_service_account_names=test-cloud \
  bound_service_account_namespaces=default \
  policies=devwebapp \
  ttl=24h

这条命令的作用是：允许default命名空间下的test-cloud服务账户通过K8s认证登录Vault，同时授予devwebapp策略对应的权限。

其他可能的排查方向 #

1. 核对Vault的K8s API地址配置 #

查看当前Vault配置的kubernetes_host是否和K8s集群的真实API地址一致：

# 获取K8s集群的真实API地址
kubectl config view --raw --minify --flatten --output='jsonpath={.clusters[].cluster.server}'

对比vault read auth/kubernetes/config返回的kubernetes_host，如果不一致，重新配置Vault的K8s认证：

vault write auth/kubernetes/config \
  kubernetes_host=$(kubectl config view --raw --minify --flatten --output='jsonpath={.clusters[].cluster.server}') \
  kubernetes_ca_cert="$KUBE_CA_CERT" \
  token_reviewer_jwt="$TOKEN_REVIEW_JWT"

2. 验证ServiceAccount Token的有效性 #

检查test-cloud的token是否包含正确的账户和命名空间信息：

TOKEN_REVIEW_SJWT=$(kubectl get secret test-cloud -o go-template='{{ .data.token }}' | base64 --decode)
# 解码token payload查看关键信息
echo $TOKEN_REVIEW_SJWT | cut -d. -f2 | base64 -d | jq

确认输出中kubernetes.io/serviceaccount/name的值是test-cloud，kubernetes.io/serviceaccount/namespace的值是default，确保和角色绑定的配置一致。

3. 检查登录请求的角色名拼写 #

确认你curl请求中的role: "devweb-app"和创建的角色名称完全一致，没有大小写或拼写错误。

4. 查看Vault日志定位细节 #

如果以上步骤都没问题，开启Vault的debug日志获取更详细的错误原因：

# 开发模式下临时开启debug日志
vault server -dev -log-level=debug
# 生产环境需修改配置文件中的log_level为debug后重启Vault，再查看日志

日志会明确说明拒绝的具体原因，比如角色绑定不匹配、token验证失败等。

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