EKS中用Helm部署TLS加密Vault对接Consul后端的配置及同Pod部署问题求助

核心解决逻辑 #

不需要强行修改Vault Helm Chart源码实现同Pod部署，全程兼容现有enableAutoEncrypt: true的Consul Helm部署配置，可同时满足三个设计目标：

• Vault只就近访问所在节点的Consul客户端，不直连Consul服务端
• 全程TLS加密，不使用跳过证书校验的不安全配置
• 解决现有配置下的x509证书信任、SAN不匹配报错

操作步骤 #

1. 实现Vault与本地Consul客户端的网络直连（无需改Vault Chart） #

之前困惑找不到同Pod部署Consul的配置，是因为没有启用Consul自带的自动注入能力：

• 确认Consul Helm部署时已开启connectInject.enabled=true配置，该功能会通过K8s Mutating Webhook，自动为带指定标签的Pod注入共享网络命名空间的Consul客户端边车
• 给Vault的StatefulSet打上自动注入标签：

  metadata:
    labels:
      consul.hashicorp.com/connect-inject: "true"
  

• 注入完成后，Vault容器会和Consul客户端边车共享同一个网络命名空间，此时Vault的Consul存储配置中，address直接填写127.0.0.1:8501即可，完全符合就近访问的设计要求。

2. 解决TLS证书校验报错 #

之前的certificate signed by unknown authority报错，根因是没有把Consul集群的根CA证书加载到Vault的信任链中，和autoEncrypt配置不存在冲突：

• 自动注入Consul边车的流程中，Webhook会自动把Consul的CA证书挂载到Vault容器内的固定路径：/consul/tls/ca/tls.crt
• 修改Vault的Consul存储配置，直接复用自动挂载的CA路径，不需要手动替换自定义证书：

  storage "consul" {
    address = "127.0.0.1:8501"
    path = "vault/"
    scheme = "https"
    # 指向Webhook自动挂载的CA文件
    tls_ca_file = "/consul/tls/ca/tls.crt"
    tls_cert_file = ""
    tls_key_file = ""
    token = "<提前为Vault生成的Consul ACL Token>"
  }
  

• 因为访问地址使用127.0.0.1，属于Consul autoEncrypt签发的客户端证书默认包含的SAN列表，不会触发之前用HOST_IP:8501访问时出现的「证书SAN不包含节点IP」的校验错误。

3. 无注入权限场景的替代方案 #

如果因为集群权限限制无法开启Mutating Webhook注入能力，可通过两个调整实现目标，无需同Pod部署：

• 不要直接使用节点HOST_IP作为访问地址，在Vault的Pod配置中添加hostAlias，把自定义域名vault-consul.local映射成本节点的HOST_IP
• 在Consul Helm的客户端配置中，给客户端证书的SAN列表额外添加对应节点IP、vault-consul.local两个值，同时通过K8s Secret把Consul的CA证书挂载到Vault Pod内，配置指向CA路径即可解决校验问题
• 注意：不建议为了简化配置开启tls_skip_verify，该配置会跳过证书链校验，存在中间人攻击风险。

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