Kubernetes Client can't be initialized with OIDC authentication

[wing011203]

Hi,
I want to report a Kubernetes Client Initialization failure issue, it may be due to OIDC authentication.

I provisioned a Kubernetes cluster service from IBM Cloud platform, and I have got the kube config file which is using OIDC for user authentication, I tried to use Fabric Kubernetes Client library to connect to the cluster, but it failed when I try to load the config and initialize the KubernetesClient.

The root cause is that some of the Kubernetes API models under package io.fabric8.kubernetes.api.model are missing.
For my case, I checked the source code, in class io.fabric8.kubernetes.client.Config, it imports below 2 models which can't be found.
import io.fabric8.kubernetes.api.model.ExecConfig;
import io.fabric8.kubernetes.api.model.ExecEnvVar;

And in below method:
private static boolean loadFromKubeconfig(Config config, String context, String kubeconfigContents, String kubeconfigPath)
When the kube config file uses OIDC authentication, it will run below source code.

As ExecConfig can't be found, line 543 will raise below error.

I have tried version both 4.4.2 and 4.7.1, the error is same.
Please check and advise how we should use this library under OIDC based authentication.

Regards,
Pan

[rkdec89]

I am encountering the same issue as wing011203 posted above, but I provisioned a Kubernetes Cluster from Oracle Cloud Infrastructure (OKE service). Please help.

[eugene-krivobokov]

Hi! I've used a bit different workaround for OIDC.
Take a look at #2111 . Maybe it will help.

[stale]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!

[manusa]

Relates to:

• .kube/config with external authentication command doesn't work #2308
• Fix #2308: kubeconfig with external authentication command doesn't work #2381

[rohanKanojia]

When I was fixing #2111 I tried it out and found out that client works with OIDC(i.e. client is able to load the token from auth-provider config). Maybe it wasn't the case when this issue was filed. I think we can close this issue.