GKE 上的 Vault - x509：无法验证 127.0.0.1 的证书，因为它不包含任何 IP SAN答案

【问题标题】：Vault On GKE - x509: cannot validate certificate for 127.0.0.1 because it doesn't contain any IP SANsGKE 上的 Vault - x509：无法验证 127.0.0.1 的证书，因为它不包含任何 IP SAN
【发布时间】：2022-08-09 21:20:29
【问题描述】：

我在 Istio 命名空间的证书管理器中为 commonName \"vault-lab.company.com\" 创建了一个证书。

然后，我使用 Reflector 将该秘密复制到 Vault 命名空间，如下所示：

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: vault-lab.company.com-cert
  namespace: istio-system
spec:
  secretName: vault-lab.company.com-cert
  commonName: vault-lab.company.com
  dnsNames:
  - vault-lab.company.com
  issuerRef:
    name: letsencrypt-prod-istio
    kind: ClusterIssuer
  secretTemplate:
    annotations:
      reflector.v1.k8s.emberstack.com/reflection-allowed: \"true\"  
      reflector.v1.k8s.emberstack.com/reflection-allowed-namespaces: \"vault\"  # Control destination namespaces
      reflector.v1.k8s.emberstack.com/reflection-auto-enabled: \"true\" # Auto create reflection for matching namespaces
      reflector.v1.k8s.emberstack.com/reflection-auto-namespaces: \"vault\" # Control auto-reflection namespaces

通过卷和volumeMounts部分成功挂载秘密值.yaml对于保险柜：

  volumes:
    - name: vault-lab-cert
      secret:
        secretName: vault-lab.company.com-cert
  volumeMounts: 
        mountPath: /etc/tls
        readOnly: true

在阅读https://github.com/hashicorp/vault/issues/212 时，我还在侦听器配置中设置了以下内容：

config: |
      ui = false
      listener \"tcp\" {
        tls_disable = false
        address = \"0.0.0.0:8200\"
        tls_cert_file = \"/etc/tls/tls.crt\"
        tls_key_file = \"/etc/tls/tls.key\"
      }
      api_addr = \"https://vault-lab.company.com:8200\"
      cluster_addr = \"https://vault-lab.company.com:8201\"

但是，我仍然看到：

Get \"https://127.0.0.1:8200/v1/sys/seal-status\": x509: cannot validate certificate for 127.0.0.1 because it doesn\'t contain any IP SANs

运行时：

kubectl exec vault-0 -- vault status

有趣的是，如果我描述Vault-0吊舱通过kubectl，我懂了：

VAULT_ADDR:                      https://127.0.0.1:8200
VAULT_API_ADDR:                  https://$(POD_IP):8200

我会错过什么？如果证书是通过 Cert Manager 配置的，我还需要做些什么吗？

根本没有关于如何设置它的大量文档。

证书验证尝试将您在请求中用作主机的内容（在您的情况下为127.0.0.1 与证书的颁发对象（在您的情况下为vault-lab.company.com）结合在一起，如果这不合适，则会出现错误。因此，要么为请求使用正确的主机，要么将 127.0.0.1 作为 IP 添加到证书中（是的，您也可以为 IP 地址创建证书）
@derpirscher - 从安全的角度来看，将 127.0.01 添加到证书中似乎并不是最好的想法。给出错误的 kubectl 命令默认将请求发送到 127.0.0.1，所以我不确定如何去改变它。它一定与 values.yaml 文件有关，对吧？
证书中有 127.0.0.1 会有什么安全问题？实际上，我认为您根本不需要 localhost 或 127.0.0.1 的任何证书，因为这些请求可以——根据定义——只能来自和定位在同一台机器上......
我的假设是这可能是中间人攻击的潜在问题，但是在阅读了 LetsEncrypt 文章后，我的假设是不正确的；您不应该添加 localhost，但 127.0.0.1 对于本机/Web 应用程序来说是可以的。我会尝试将其添加到证书中，然后看看我是如何进行的。谢谢指点：）

标签： ssl google-kubernetes-engine hashicorp-vault

【解决方案1】：

当您运行vault status 时，二进制文件作为客户端运行，不知道服务器配置，即使它运行在同一台机器或容器上。这意味着vault status 无法读取配置文件的listener 节。它默认为您的证书中缺少的https://127.0.0.1:8200。解决方案不是添加此 IP 地址，而是告诉 Vault CLI 在哪里可以找到服务器。

您可以确认这是此命令的问题（应该可以，假设您的证书正常）：

kubectl exec vault-0 -- vault status --address https://vault-lab.company.com:8200

要让客户端自动获取 API 地址，请将容器中的 VAULT_ADDR environment variable 设置为：

VAULT_ADDR=https://vault-lab.company.com:8200

【讨论】：

【解决方案2】：

谢谢@ixe013。我之前一直在使用外部文件设置 env，在切换到 vault.env 时开始遇到这个问题。直到阅读您的评论才意识到新的 vault.env 文件仅适用于 systemd 单元，因此出现错误。

【讨论】：