Support for multiple Vault Kubernetes authentication paths

[jesumyip]

I'm looking at https://developer.hashicorp.com/vault/docs/auth/kubernetes#via-the-api and https://computingforgeeks.com/how-to-integrate-multiple-kubernetes-clusters-to-vault-server/

Based on these, Hashicorp supports multiple Kubernetes authentication configuration sets. I have multiple Kubernetes ArgoCD clusters where I want argocd-vault-plugin to work using the k8s authentication method.

I configured Hashicorp vault to have 2 auth methods using kubernetes - each in a different path. One uses the default kubernetes path, and another uses argocd2 path.

I find that no matter what I do, argocd-vault-plugin will always send the default authentication request to /v1/auth/kubernetes/login URL of my Hashicorp vault instance. Is there a way to force argocd-vault-plugin to use /v1/auth/arogcd2/login instead?

[pre]

We have wrapped argocd-vault-plugin behind a shell script from where we are in 100% control of which authentication mechanism is used (we have multiple).

Instead of using argocd-vault-plugin directly as a ArgoCD Config Management Plugin (CMP), we add that wrapper shell script as the CMP.

Because the shell script is 100% in our hands, argocd-vault-plugin can remain agnostic about the details.

[jesumyip]

How does this solve the problem? In Vault, I can specify /auth/kubernetes as one auth path. I can also specify /auth/myauth as another. Both use kubernetes as the auth scheme.

The reason I need this is I have multiple ArgoCD clusters that have argocd-vault-plugin installed in them. They all use Kubernetes auth and so they all have different ca.crt certs that need to be registered in Vault.

Could you kindly clarify?

Anyway I think the solution is to specify AVP_K8S_MOUNT_PATH.

[pre]

When you register a bash script as the ArgoCD CMP and then run argocd-vault-plugin from that bash script you can define anything you need before argocd-vault-plugin is invoked.

We use both Vault AppRoles and Vault JWT OIDC for authentication. I don't know about the specifics of the Vault Kubernetes authentication method but I don't think there is anything special there.

Not related to this issue - however - consider the Vault JWT Oidc instead of Vault Kubernetes authentication.

With Vault Kubernetes, Vault needs to be aware of your Kubernetes setup. With JWT OIDC, you can just tell Vault your Kubernetes API server's OIDC metadata endpoint, grant the Kubernetes ServiceAccount with a correct JWT audience and that's it. The Kubernetes API servers act as an OIDC provider out-of-the-box.