Sorting out the different vault services created by helm chart

When using the helm vault chart it will create a bunch of different services. Among these are vault, vault-active, vault-standby and more.

Most interesting here is vault and vault-active. As I understand it the vault-active' will go directly to the active vault pod and vault` will go to any available node, but will redirected to the active.

The problem is that only one service can have a valid tls certificate as the certificate, any other will have wrong address. So to interact securely and effortlessly I have to select which service the certificate should match.

So should vault or vault-active be the primary service for normal usage in a k8s-cluster.

The problem is worsened by how other k8s-objects created by the helm chart differ. The openshift Route-object want to use the vault-active-service, but the vault-agent want to used the vault-service; making it difficult to make them both happy.

That’s not true. TLS certificates can simultaneously support multiple names.

It depends.

For Vault OSS, there’s not much point load-balancing traffic across the standby nodes, which are just going to forward it to the active node anyway.

For Vault Enterprise, there are also performance standbys, which can handle read traffic without involving the active node. In this case there is a value to load-balancing traffic to performance standby nodes.

You’re of course completely correct; the TLS certificate can support all the different names.

It’s however difficult to see a reason why the vault-agent and the openshift route should not use the same address. Luckily there is a way to override this in the vault-agent through .Values.global.externalVaultAddr.

I think I only needed some rubber ducking. Thanks :slight_smile:

Wrong path again, even though externalVaultAddr changes the address used by the vault-agent. This sets an external address for the vault instance. Which of course is not at all what I want.