Nullpointer in 6.12.1 with Config.empty client setup

[adenhartog]

Describe the bug

We use ConfigBuilder(Config.empty()) to create an empty config so that we have no autoconfig or other interference from the presence of a pre-existing ~/.kube/config file. We do that because we run our app in container but the OpenShift serviceaccount associated with the Pod does not have the necessary rights.

This works on 6.12.0 but gives a null pointer on 6.12.1.

Fabric8 Kubernetes Client version

6.12.1

Steps to reproduce

In Kotlin:

fun main() {
    val config = ConfigBuilder(Config.empty())
        .withMasterUrl("https://my.openshift.server.api:443")
        .withUsername("validusername")
        .withPassword("validpassword")
        .build()

    val kubernetesClient = KubernetesClientBuilder()
        .withConfig(config)
        .build()
        .adapt(OpenShiftClient::class.java)

    println(kubernetesClient.pods().list().items.first().metadata.name)
}

Expected behavior

The name of a pod on stdout, and not an Exception.

Runtime

OpenShift

Kubernetes API Server version

other (please specify in additional context)

Environment

other (please specify in additional context)

Fabric8 Kubernetes Client Logs

Exception in thread "main" io.fabric8.kubernetes.client.KubernetesClientException: Cannot invoke "io.fabric8.kubernetes.api.model.AuthProviderConfig.getName()" because the return value of "io.fabric8.kubernetes.client.Config.getAuthProvider()" is null
	at io.fabric8.kubernetes.client.dsl.internal.OperationSupport.waitForResult(OperationSupport.java:509)
	at io.fabric8.kubernetes.client.dsl.internal.BaseOperation.list(BaseOperation.java:451)
	at io.fabric8.kubernetes.client.dsl.internal.BaseOperation.list(BaseOperation.java:98)
	at MainKt.main(Main.kt:55)
	at MainKt.main(Main.kt)
Caused by: java.lang.NullPointerException: Cannot invoke "io.fabric8.kubernetes.api.model.AuthProviderConfig.getName()" because the return value of "io.fabric8.kubernetes.client.Config.getAuthProvider()" is null
	at io.fabric8.kubernetes.client.utils.OpenIDConnectionUtils.persistKubeConfigWithUpdatedAuthInfo(OpenIDConnectionUtils.java:248)
	at io.fabric8.openshift.client.internal.OpenShiftOAuthInterceptor.persistNewOAuthTokenIntoKubeConfig(OpenShiftOAuthInterceptor.java:157)
	at io.fabric8.openshift.client.internal.OpenShiftOAuthInterceptor.lambda$null$0(OpenShiftOAuthInterceptor.java:79)
	at java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:646)
	at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510)
	at java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2179)
	at io.fabric8.kubernetes.client.http.StandardHttpClient.lambda$completeOrCancel$10(StandardHttpClient.java:142)
	at java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:863)
	at java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:841)
	at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510)
	at java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2179)
	at io.fabric8.kubernetes.client.http.ByteArrayBodyHandler.onBodyDone(ByteArrayBodyHandler.java:51)
	at java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:863)
	at java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:841)
	at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510)
	at java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2179)
	at io.fabric8.kubernetes.client.okhttp.OkHttpClientImpl$OkHttpAsyncBody.doConsume(OkHttpClientImpl.java:136)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
	at java.base/java.lang.Thread.run(Thread.java:1583)

Additional context

Probably caused by: "fix: updated OpenId access and refresh token persistend in in-memory"
4ec7c99#diff-89177530c5f2c684ec110696ebeb2676d2aed8abc96a6919752c2d214e82233f

Things I have tried:

1. Creating an OpenShiftConfig instead of a generic Config, but this gives the same error.
2. Creating an AuthProviderConfig through its respective builder and passing that to the Config. That fixes the original problem but fails a bit later with: Cannot invoke "io.fabric8.kubernetes.api.model.AuthProviderConfig.getConfig()" because the return value of "io.fabric8.kubernetes.api.model.AuthInfo.getAuthProvider()" is null
3. When I omit the Config.empty() param to ConfigBuilder(), this works only when the current-context in ~/.kube/config is present and has a valid token when I do this on my machine. But in the Pod, this causes the Openshift serviceaccount to win out over the credentials we pass, so this also fails. After performing an oc logout on my machine, I get the original null pointer.

Environment: both Linux (in a Pod) and Windows

Not relevant since this is entirely a client side issue, but since this info is requested:
Kubernetes Server Version: v1.27.10+28ed2d7

[rohanKanojia]

@adenhartog Hello, I tried reproducing the issue and could reproduce it with KubernetesClient v6.12.1

However, when I run the same code with KubernetesClient v6.13.0 I don't see the NPE anymore. Could you please check if issue is resolved with the newer version?

[tinystorm]

I believe it is.
#5221

[rohanKanojia]

@tinystorm : Thanks for confirming! I see #5221 has a different NPE stack trace compared to this issue. I think this was a new regression from #5888

However, with v6.13.0 I am not able to reproduce. Maybe with #5914 this issue got fixed as we're using Optional.map to filter out null AuthProviderConfig scenario

kubernetes-client/kubernetes-client-api/src/main/java/io/fabric8/kubernetes/client/utils/OpenIDConnectionUtils.java

Line 194 in 6b7d516

Optional.of(currentConfig).map(Config::getAuthProvider).map(AuthProviderConfig::getConfig)

[adenhartog]

I can also confirm that this issue is fixed in 6.13.0. Thanks!

[rohanKanojia]

@adenhartog : Shall we close this issue then :-) ?

[adenhartog]

Resolved