Multiple Kubernetes clusters using one vault cluster

[SecDWizar]

We have multiple Kubernetes clusters authentication vs. a single shared vault cluster.

AKubernetes cluster that runs vault can be configured via vault-config-operator as is normally documented,
However, another Kubernetes cluster, one that vault does not run on, cannot be configured using kubernetesauthengine, as far as I can tell.

KIND:     KubernetesAuthEngineConfig
VERSION:  redhatcop.redhat.io/v1alpha1

RESOURCE: tokenReviewerServiceAccount <Object>

DESCRIPTION:
     TokenReviewerServiceAccount A service account JWT used to access the
     TokenReview API to validate other JWTs during login. If not set, the JWT
     submitted in the login payload will be used to access the Kubernetes
     TokenReview API.

FIELDS:
   name <string>
     Name of the referent. More info:
     https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
     TODO: Add other useful fields. apiVersion, kind, uid?

In kubernetesauthengineconfig_types.go PrepareInternalValues (L92), if there is a tokenReviewerServiceAccount it goes to getJWTToken (L112) i.e. generates a token using token-request API.

I suggest the following tiny change:

1. Add another field called token under "tokenReviewerServiceAccount"

2. Add to getJWTToken (kubernetesauthengineconfig_types.go L112) such that (pseudo)

   if kc.Spec.TokenReviewerServiceAccount.token != nil {
      return kc.Spec.TokenReviewerServiceAccount.token
   }
   

   Or it can be done directly in PrepareInternalValues (L92) between L96-L97 with similar logic.

   Bottom line that it'll configure d.Spec.retrievedTokenReviewerJWT with the (now) supplied JWT token (of a sa with auth-delegator role on the other cluster) to be used for the vault configuration api call (payload as defined in tomap (L212)

3. And of course update accordingly the crd and doc (with the new "tokenReviewerServiceAccount.token"

That way we can use one Vault for multiple Kubernetes clusters and configure kubernetes authentication for them using this vault-config-operator exactly as planned.

If there is another way to achieve this now, please advice.