Home > database >  Vault On GKE - x509: cannot validate certificate for 127.0.0.1 because it doesn't contain any I
Vault On GKE - x509: cannot validate certificate for 127.0.0.1 because it doesn't contain any I

Time:08-10

I've created a certificate for the commonName "vault-lab.company.com" within Certificate Manager in the Istio namespace.

I've then used Reflector to copy that secret across to the Vault namespace, like so:

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

The secret is successfully mounted via the volumes and volumeMounts section of the values.yaml for Vault:

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

And in reading https://github.com/hashicorp/vault/issues/212, I've set the following as well in the listener configuration:

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"

However, I'm still seeing:

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

When running:

kubectl exec vault-0 -- vault status

Interestingly, if I describe the vault-0 pod via kubectl, I see:

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

What could I be missing? Is there something more I need to do if the certificate is configured via Cert Manager?

There's not a great deal of documentation on how to set this up at all.

CodePudding user response:

When you run vault status, the binary runs as a client, unaware of the server configuration, even if it's running on the same machine or container. That means vault status can't read the listener stanza of your configuration file. It defaults to https://127.0.0.1:8200 that is missing from your certificate. The solution is not to add this IP address, but to tell Vault CLI where to find the server.

You can confirm that this is the problem with this command (should work, assuming your certificate is OK):

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

For the client to pick up the API address automatically, set the VAULT_ADDR environment variable in your container to:

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

CodePudding user response:

Thanks @ixe013. I had previously been setting the env using an external file and upon switching to the vault.env started encountering this issue. Didnt realize till reading your comment that the new vault.env file only applies to the systemd unit, hence the error.

  • Related