Lens: Cannot connect to k8s behind VPN on Mac OS

[ITD27M01]

Describe the bug
The issue described: https://github.com/kubernetes/kubectl/issues/48
And solution already implemented in kubectl: https://github.com/kubernetes/release/issues/469

Kubectl works fine, but lens doesnt

On macOS, if a Go program is compiled with CGO_ENABLED=0 then Go uses its own internal network name resolver. This resolver only knows about /etc/resolv.conf and doesn’t know about the libSystem (macOS libc) library and its name resolution functions.

macOS (like most modern OSes) has smarter DNS lookups than just using an /etc/resolv.conf which allows it to smoothly handle switching networks.

When a VPN is being used then DNS lookups will be split between the VPN’s DNS servers and your ISP’s DNS servers, depending on the hostname.

You can set up custom name servers for certain domains by creating resolv.conf style files in /etc/resolver/. This is what your VPN software is doing behind the covers.

This issue can be reproduced by creating /etc/resolver/ resolver for a particular cluster. This resolver must use different DNS servers than /etc/resolv.conf has. And only these different DNS servers have to resolve cluster fqdn.

To Reproduce
Steps to reproduce the behavior:

1. Install Lens on Mac OS
2. Connect to VPN network, such as corporate network
3. Try to connect to cluster behind VPN
4. See error

Or

1. Install Lens on Mac OS
2. create /etc/resolver/ resolver for a particular cluster
3. Try to connect to the cluster
4. See error

Expected behavior
The same behavior as for kubectl - I can work with cluster.

Screenshots

Environment (please complete the following information):

• Lens Version: 3.5.3
• OS: Mac OS
• Installation method (e.g. snap or AppImage in Linux): brew cask install lens

Logs:
When you run the application executable from command line you will see some logging output. Please paste them here:

Connecting ...
Authentication proxy started
2020/08/19 18:47:39 http: proxy error: dial tcp: lookup api.cluster.example.com on 192.168.1.1:53: no such host

[jakolehm]

Lens is using upstream kubectl binaries and those have this limitation. Lens project probably needs to build own kubectl binaries with right build flags.

[ITD27M01]

@jakolehm
I've installed kubectl from brew (brew install kubectl) and it works fine:

> kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.8", GitCommit:"9f2892aab98fe339f3bd70e3c470144299398ace", GitTreeState:"clean", BuildDate:"2020-08-14T11:09:22Z", GoVersion:"go1.14.7", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"17+", GitVersion:"v1.17.1+b83bc57", GitCommit:"b83bc57", GitTreeState:"clean", BuildDate:"2020-07-30T20:54:30Z", GoVersion:"go1.13.4", Compiler:"gc", Platform:"linux/amd64"}

Maybe there any way to switch to brew kubectl?

[ITD27M01]

This helps me as a workaround:

cp /usr/local/bin/kubectl ~/Library/Application\ Support/Lens/binaries/kubectl/1.17.4

[ITD27M01]

Maybe the fix is available on 1.18 version for kubectl.

[rcoup]

Withe Lens 3.6.0, I can workaround by setting the _Path to Kubectl binary_ to /usr/local/bin/kubectl (ie homebrew) in Lens...Preferences

[ITD27M01]

Withe Lens 3.6.0, I can workaround by setting the Path to Kubectl binary to /usr/local/bin/kubectl (ie homebrew) in Lens...Preferences

It looks like a solution, isn't it?

[rcoup]

Dunno about a "solution" since it's still broken out of the box.

I guess Lens could bundle the Homebrew kubectl binary on macOS instead of the upstream one (until upstream gets fixed)