External Vault Kubernetes Auth

Going through the guide on Kubernetes auth, is the Kubernetes auth method even applicable using an external vault (vault is not running Kubernetes). Kubernetes - Auth Methods | Vault by HashiCorp

Ultimately I want to issue certs to applications running in K8s from our external vault: Configure Vault as a Certificate Manager in Kubernetes with Helm | Vault - HashiCorp Learn

What auth method would work best in this case if Kubernetes auth isn’t applicable?

Yes it is, as long as your pointed to Kubernetes cluster’s API server is reachable by your Vault cluster.

If you are not a huge fan of the Kubernetes auth method, you can always use the OIDC auth replacement with Vault acting as an OIDC provider.

Yes, the Kubernetes cluster API is available to the Vault cluster. For the Kubernetes auth method, where do I find the value for this specified in the walk-through? It seems like it is assuming Vault is running kubernetes

token_reviewer_jwt="<your reviewer service account JWT>"

The token_reviewer_jwt is a token that is used to send a TokenReview request to your designated Kubernetes server. So this token needs to be obtained from your Kubernetes server from a service account with the right capabilities.

Would this method be applicable? It mentioned omitting the jwt token when configuring the auth method, but I assume this is only for when running vault in Kubernetes:

In your case, yes this would be applicable. In this case it will use the requesting service account’s JWT as the token reviewer. Do keep in mind that the requesting service account needs to have the capabilities to perform a token review.

Requesting service account meaning the account currently logged into vault when performing the vault write auth/kubernetes/config ?

Yes! At least if you are then using parameters derived from the Kubernetes cluster that is targeted in your auth/kubernetes config.

So the vault account you are using and the service account you’ve defined on the k8s cluster need to have the same name?

Yes, they need to be the exact same account. You will be using the service account token from the privileged service account you’ve defined in your k8s cluster to login to Vault. This service account in turn can also verify itself.

Gotcha. So in this order: define the service account in K8s, take the token there and define it in Vault and attach the appropriate policies, then setup the kubernetes auth in Vault

Exactly!
Just make sure that the service account in K8s has the right capabilities to make the TokenReview request.

define the service account in K8s, take the token there and define it in Vault and attach the appropriate policies, then setup the kubernetes auth in Vault

Just for a bit of a sum up. This approach is the will be the long-lived-auth approach.
If you want to go ahead and use the use-vault-client-jwt-as-the-reviewer approach, you can go ahead and emit the second step (take the token there and define it in Vault) and set disable_local_ca_jwt to true.
For the one other approach, please have a look here.

I hope this helps enough!