Kind集群部署Vault配置GCP KMS自动解封故障排查

不需要为每个Vault副本单独创建KMS密钥。同一Raft高可用集群内的所有Vault实例共用同一个CKMS密钥即可完成自动解封，这是官方标准支持的配置，多副本独立创建密钥反而会导致集群无法正常同步解封状态。

常见故障原因排查 #

按出现概率从高到低排序：

• Helm配置语法错误导致凭证未挂载
  官方HashiCorp Vault Helm Chart的server.extraVolumes字段直接接收标准Kubernetes Volume定义，不支持type: secret这类简写语法。你当前的配置不会把kms-credsSecret正确挂载到容器内，GOOGLE_APPLICATION_CREDENTIALS指定的路径下实际不存在凭证文件，Vault根本无法调用KMS接口。
  正确的卷配置需要同时声明卷和对应挂载点，参考如下：

  server:
    extraVolumes:
      - name: kms-creds
        secret:
          secretName: kms-creds
    extraVolumeMounts:
      - name: kms-creds
        mountPath: /vault/userconfig/kms-creds
        readOnly: true
  

  另外你当前配置把injector.logLevel写在了server层级下，正确位置是和server平级的顶层injector字段，该错误不影响解封功能，但说明配置存在层级错位，建议同步修正。
• 服务账号权限配置错误
  你给服务账号绑定的Cloud KMS Service Agent角色是GCP内部托管服务使用的角色，自定义服务账号绑定该角色不会获得CKMS操作权限。自定义服务账号完成解封只需要绑定roles/cloudkms.cryptoKeyEncrypterDecrypter角色即可，不需要授予Owner等过宽权限，注意权限需要绑定到你创建的vault-helm-unseal-key具体密钥资源上，如果没有配置资源层级权限继承，绑定到项目或密钥环级不会生效。
• 未执行集群初始化操作
  配置GCP KMS自动解封不会跳过Vault集群初始化流程。部署完成后第一个副本会正常启动，但会停留在等待初始化状态，需要手动执行vault operator init完成初始化，初始化过程中Vault会自动用KMS加密根密钥，后续所有副本重启都会自动完成解封。未初始化状态下其余两个副本无法加入Raft集群，会一直返回密封提示。
• 本地集群网络连通性问题
  你使用kind部署本地集群，需要确认集群节点有正常的公网出口能访问GCP KMS服务端点，可以进入Vault容器执行curl -v https://cloudkms.googleapis.com验证连通性，如果请求超时、被本地防火墙拦截，或者没有配置正确的代理规则，Vault无法调用KMS接口自然无法完成解封。
• 凭证文件内容或权限异常
  确认kms-credsSecret中存储凭证的键名确实是credentials.json，如果键名不匹配，挂载后不会生成对应路径的文件；同时确认Secret挂载后的文件权限为0644，Vault默认以100号用户运行，没有读权限的话无法加载凭证。
• KMS密钥状态异常
  登录GCP控制台确认vault-helm-unseal-key处于启用状态，没有配置禁用规则、也没有设置计划删除，密钥环和密钥的区域配置和seal块中声明的global一致。

内容的提问来源于stack exchange，提问作者Paul Barrié