Vault agent's template do not respect tls_server_name

[clkamp]

Describe the bug
We have a vault server at one ip, which has a cert for a name and a second machine running agent, but connects to the vault server by ip and uses tls_server_name. This works fine for approle auth, but fails for a template.

To Reproduce
Steps to reproduce the behavior:

1. Set up vault server under $IP, with a valid cert for $NAME
2. Setup a approle auth and get login data
3. On another machine start agent with config see below
4. Template is not expanded, log shows error because of no valid cert for $IP

Expected behavior
tls_server_name should be also respected for templating

Environment:

• Vault Server Version (retrieve with vault status): 1.4.2
• Vault CLI Version (retrieve with vault version): 1.4.2
• Server Operating System/Architecture: Debian 10 / amd64

Vault agent configuration file(s):

pid_file = "/home/vault/pidfile"

vault {
  address = "https://$IP:8200"
  tls_server_name = "$NAME"
}

auto_auth {
  method "approle" {
    config = {
      role_id_file_path = "/etc/vault/role-id"
      secret_id_file_path = "/etc/vault/secret-id"

      remove_secret_id_file_after_reading = false
    }
  }

  sink "file" {
    config = {
      path = "/home/vault/token"
    }
  }
}

cache {
  use_auto_auth_token = true
}

listener "unix" {
  address = "/home/vault/vault.socket"
  tls_disable = true
}

template {
  source = "XXX"
  destination = "YYY"
}

XXX template:

{{ with secret "transit/keys/ZZZ" }}{{ .Data.data.keys }}{{end}}

If there is anything missing, please just ask.

[issacg]

I think this is the root cause for hashicorp/vault-k8s#150

[issacg]

Interestingly, setting VAULT_TLS_SERVER_NAME does seem to work as a workaround.

[issacg]

Ping @ vault team.

Any update on getting this fixed? It seems a low hanging-ish bug, with a proposed PR, and I'd really love to stop using TLS_SKIP_VERIFY throughout my k8s injected agent sidecars without resorting to patching and custom binaries on my end.

Thanks 🙏