keycloak-containers | ARCHIVED Containers for the no longer supported WildFly | Identity Management library

The way KUBE_PING works is similar to running kubectl get pods inside one Keycloak pod to find the other Keycloak pods' IPs and then trying to connect to them one by one. Except Keycloak does that by querying the Kubernetes API directly instead of running kubectl.

To do that, it needs credentials to query the API, basically an access token.

You can pass your token directly, if you have it, but its not very secure and not very convenient (you can check other options and behavior here).

Kubernetes have a very convenient way to inject a token to be used by a pod (or a software running inside that pod) to query the API. Check the documentation for a deeper look.

The mechanism is to create a service account, give it permissions to call the API using a RoleBinding and set that account in the pod configuration.

That works by mounting the token as a file at a known location, hardcoded and expected by all Kubernetes clients. When the client wants to call the API it looks for a token at that location.

Although not very convenient, you may be in the even more inconvenient situation of lacking permissions to create RoleBindings (somewhat common in more strict environments).

You can then ask an admin to create the service account and RoleBinding for you or just (very unsecurely) pass you own user's token (if you are capable of doing a kubectl get pod on Keycloak's namespace you have the permissions) via SA_TOKEN_FILE environment variable.

Create the file using a secret or configmap, mount it to the pod and set SA_TOKEN_FILE to that file location. Note that this method is specific to Keycloak.

If you do have permissions to create service accounts and RoleBindings in the cluster:

An example (not tested):