KubernetesClientException if Wildcard (*) in NO_PROXY environment variable

[iampratapak]

Describe the bug

If the NO_PROXY environment variable contains wildcards, a KubernetesClientException is thrown when attempting to create a KubernetesClient. 

KubernetesClient kubernetesClient = new KubernetesClientBuilder().build();

If the NO_PROXY environment variable has wildcards, for example *.domain.com, then client creation is failing with the below exception.

io.fabric8.kubernetes.client.KubernetesClientException: Invalid proxy server configuration
java.net.MalformedURLException: NO_PROXY URL contains invalid entry: '*.domain.com'

Fabric8 Kubernetes Client version

6.1.1

Steps to reproduce

1. Set wildcards in the NO_PROXY environment variable
   NO_PROXY: localhost,127.0.0.1,*.google.com, *.github.com
2. Try to create a Kubernetes client

Expected behavior

We should be able to create Kubernetes clients even when the NO_PROXY environment variable contains wildcard expressions.

Runtime

other (please specify in additional context)

Kubernetes API Server version

other (please specify in additional context)

Environment

Windows

Fabric8 Kubernetes Client Logs

Caused by: io.fabric8.kubernetes.client.KubernetesClientException: Invalid proxy server configuration
	at io.fabric8.kubernetes.client.utils.HttpClientUtils.applyCommonConfiguration(HttpClientUtils.java:184)
	at io.fabric8.kubernetes.client.okhttp.OkHttpClientFactory.createHttpClient(OkHttpClientFactory.java:96)
	at io.fabric8.kubernetes.client.okhttp.OkHttpClientFactory.createHttpClient(OkHttpClientFactory.java:32)
	at io.fabric8.kubernetes.client.utils.HttpClientUtils.createHttpClient(HttpClientUtils.java:149)
	at io.fabric8.kubernetes.client.DefaultKubernetesClient.<init>(DefaultKubernetesClient.java:163)
	... 78 more
Caused by: java.net.MalformedURLException: NO_PROXY URL contains invalid entry: '*.domain.com'
	at io.fabric8.kubernetes.client.utils.HttpClientUtils.isHostMatchedByNoProxy(HttpClientUtils.java:206)
	at io.fabric8.kubernetes.client.utils.HttpClientUtils.getProxyUrl(HttpClientUtils.java:64)
	at io.fabric8.kubernetes.client.utils.HttpClientUtils.applyCommonConfiguration(HttpClientUtils.java:173)
	... 82 more

Additional context

[opc@fabric-demo-bastion-2 ~]$ kubectl version WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short. Use --output=yaml|json to get the full version. Client Version: version.Info{Major:"1", Minor:"25", GitVersion:"v1.25.0", GitCommit:"a866cbe2e5bbaa01cfd5e969aa3e033f3282a8a2", GitTreeState:"clean", BuildDate:"2022-08-23T17:44:59Z", GoVersion:"go1.19", Compiler:"gc", Platform:"linux/amd64"} Kustomize Version: v4.5.7 Server Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.5", GitCommit:"c999fea1e6dbf111d64000dfaaff45edaa4c34d2", GitTreeState:"clean", BuildDate:"2022-01-11T12:16:14Z", GoVersion:"go1.16.12 BoringCrypto", Compiler:"gc", Platform:"linux/amd64"} WARNING: version difference between client (1.25) and server (1.22) exceeds the supported minor version skew of +/-1

[iampratapak]

Similar to Wildcard (*) in NO_PROXY environment variable is not honored

[shawkins]

@pratapgowda007 see #4247 - the outcome there was to keep the no proxy matching as simple as possible and not support any meta characters.

[manusa]

This is the expected behavior and honors the spec in https://www.gnu.org/software/wget/manual/html_node/Proxies.html

Your configuration should be changed to:
NO_PROXY: localhost,127.0.0.1,.google.com,.github.com

[iampratapak]

Thanks, @shawkins and @manusa, for the quick response. So the GNU Emacs Spec was not considered to keep no_proxy matching as simple as possible and not to support any meta characters.

I'll change my NO_PROXY settings to not have any wildcards and proceed.

[manusa]

To close the issue, we need to add a note in the CHANGELOG.md file and in the GitHub release indicating the behavioral breaking change.

[rohanKanojia]

What needs to be done in order to close this issue here? There have been two releases since this issue was opened. Where should we add note about this behavioral change? Should we add this as a FAQ instead?

[manusa]

What needs to be done in order to close this issue here?

we need to add a note in the CHANGELOG.md file and in the GitHub release indicating the behavioral breaking change.

Where should we add note about this behavioral change?

• in the CHANGELOG.md (whatever the version was)
• in the GitHub release (whatever the version was)

Should we add this as a FAQ instead?

s/instead/additionally

;)