Reload KubernetesClient's Config from kubeconfig contents

[anilporiya]

Hi team,

We are working with the fabric8io's KubernetesClient and looking for a way to reload the client's Config from kubeconfig contents without having to rebuild the client.

Currently, we are watching custom resources in a Kubernetes namespace and building the KubernetesClient using a Config. The config is formed using

public static Config fromKubeconfig(String kubeconfigContents) {
    return fromKubeconfig((String)null, kubeconfigContents, (String)null);
  }

and the client using

KubernetesClient client = new KubernetesClientBuilder().withConfig(config).build();

The client is then used to get the informer factory, create shared index informer, and add event handlers.

Kubernetes Client version used: 6.12.1

Q: Now during rotation scenarios for kubeconfig, we would want to update the client to use the new kubeconfig. I see ways to refresh the Config, but nothing that updates the client to use the refreshed Config.

Is there any mechanism to transparently update the client's Config without having to rebuild the client and informers [and I am missing it]?

I am assuming the informers will start failing once the Config points to expired content.

Thanks, Anil.

[manusa]

Is there any mechanism to transparently update the client's Config

No, or at least it shouldn't be possible. You can modify parts of the config using its setters, but this mighty also bring unexpected results.

In order to prevent additional issues and side-effects (such as problems with ongoing watchers, etc.), you should close the client using the prior config and create a new one using the updated config.

You can also specify which are the rotating scenarios and properties/fields that get updated. There are already parts of the config (such as the token) that do get updated.

[anilporiya]

Hi @manusa Thanks for the response.

You can also specify which are the rotating scenarios and properties/fields that get updated. There are already parts of the config (such as the token) that do get updated.

The rotating scenarios include rotation of the kubeconfig and the properties/fields under question are mainly the token and certificate-authority-data, i.e. caCertData of Config.

So if the informers start failing [because of kubeconfig change] and ONLY the token would have been updated, then informer would recover inherently?

[manusa]

The rotating scenarios include rotation of the kubeconfig and the properties/fields under question are mainly the token and certificate-authority-data, i.e. caCertData of Config.

The token does get refreshed (and updated) in the TokenRefreshInterceptor.

I don't think Certificate rotation is considered ATM (AFAIR). Maybe we want to add a different interceptor for this purpose. Is there any (k8s) spec defining in which ways the certificates are rotated?

[anilporiya]

Hi @manusa, apologies for delayed response on this.

I am not sure I got your question regarding the spec for certificate rotation. The CA certificate in the kubeconfig should be like any other certificate rotation scenario? Maybe https://kubernetes.io/docs/tasks/tls/manual-rotation-of-ca-certificates/ answers your question?

Since seamless reconnect is possible during token refresh scenarios, maybe there should be an interceptor for the CA certificate as well so that the client inherently updates the cert data as well?