Disabling SSL for k8s auth method

[Reifier]

Is your feature request related to a problem? Please describe.
I have two k8s clusters in gke. One of them runs my application, another one runs vault. They are in separate projects and are connected over vcp peering. The application cluster is private and has a private master endpoint. That makes it impossible to access that endpoint directly from another vpc. Proxy has to be used: https://cloud.google.com/solutions/creating-kubernetes-engine-private-clusters-with-net-proxies

I've tried using http proxy, however, vault-init container has this issue: kelseyhightower/vault-init#16.

So I tried using a tcp proxy to access master directly. And vault does get to master through proxy but master cert does not match the ip address of the proxy and ssl connection gets refused with:

# curl -k --request POST --data '{"jwt": "'"$KUBE_TOKEN"'", "role": "scorpion"}' $VAULT_ADDR/v1/auth/kubernetes/login | jq
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1105  100   220  100   885    367   1479 --:--:-- --:--:-- --:--:--  1844
{
  "errors": [
    "Post https://10.48.24.34:443/apis/authentication.k8s.io/v1/tokenreviews: x509: certificate is valid for 35.236.224.245, 10.48.96.1, 35.245.183.91, 35.245.219.73, 35.236.226.10, 10.48.36.2, not 10.48.24.34"
  ]
}

I tried to see if it's possible to customize master cert to include the desired ip, but it is not possible to do so on gke.

Describe the solution you'd like
The only solution I see is to allow to use a connection without SSL for now, but I can't turn of SSL verification on kuberentes method. I understand that it is necessary and defeats the whole purpose of authorization, but I am on internal net and literally ran out of options to make this work. Vault can still be useful for us and still want it for key managing, recycling, auth on per namespace/cluster/app basis, but I don't want to run a VM and create infra around it. UnSSLed connection for auth methods should be an option.

Later when google allows cert modifications or our situation changes we could fix this. Otherwise obstructs implementation in our org.
Describe alternatives you've considered
Described above.

Explain any additional use-cases
If there are any use-cases that would help us understand the use/need/value please share them as they can help us decide on acceptance and prioritization.

Additional context
Add any other context or screenshots about the feature request here.

[catsby]

Hello - I'm going to transfer this issue over to github.com/hashicorp/vault-helm

[Reifier]

Aren't k8s auth method features in realm of the core vault?

[pcman312]

@Reifier I'm transferring this over to https://github.com/hashicorp/vault-plugin-auth-kubernetes as this is related to Kubernetes auth, not the helm chart for deploying Vault to Kubernetes. Apologies for the confusion!

[eekwong]

Well +1
I have the same situation... either

1. the token_review.go transport "InsecureSkipVerify: <true|false>" in the transport with a TCP proxy stated above,
2. the token_review.go transport has the "Proxy" support and follow something like this: https://cloud.google.com/solutions/creating-kubernetes-engine-private-clusters-with-net-proxies to setup the Privoxy proxy,
3. or Use tcp proxy state aboved, and in the vault server, go set up an IPTables nat rule (DNAT) to bypass the SNI check

Can we have an update from Hashicorp?

[eekwong]

Worked with HashiCorp support engineer and got a stunnel working. You need to create a private SSL cert that has the right CN and SAN.

[tomhjp]

Would removing the requirement for a CA certificate to be configured solve this, as requested in #62, or am I missing some other requirements? i.e. is it ok for the proxy -> private master endpoint to be plain http, or does that need to support unverified https?