Config::infer can return in-cluster config outside cluster with rustls feature

[webern]

I think there is a problem with this code branch:
https://github.com/kube-rs/kube-rs/blob/master/kube/src/config/mod.rs#L94...L97

This takes us to:
https://github.com/kube-rs/kube-rs/blob/b7fe7485a5661bdec398377109801e675db8aaee/kube/src/config/incluster_config.rs#L22...L29

Where we always return an on-cluster URL even if we are not running on a cluster.

So the issue is, if I want to use a KUBECONFIG, off-cluster with Rustls, I never make it to the KUBECONFIG code branches.

One simple fix would be to check for the absence of KUBECONFIG at https://github.com/kube-rs/kube-rs/blob/master/kube/src/config/mod.rs#L94 but that might be a slightly different behavior than advertised in the documentation.

[webern]

Ugh, I did a workaround but found that my kubeconfig file has the server address as https://127.0.0.1[...]. This was created by kind for local development. Anyway, when I workaround the problem described above to use my kubconfig file, Rustls still errors due to the "invalid dns name" rustls/hyper-rustls#84

[kazk]

Closing as duplicate of #153. We keep track of rustls issues with a label https://github.com/kube-rs/kube-rs/labels/rustls

[kazk]

Where we always return an on-cluster URL even if we are not running on a cluster.

Well, this might be a new issue.

[webern]

OK, but are you aware that the rustls workaround linked to in this issue prevents a KUBECONFIG from ever being used. So, if my KUBECONFIG specifies https://somekubernetes.com, the bug I've mention exists where the KUBECONFIG will never be read. In this case the rustls "invalid DNS" is not the problem.

Edit: just saw you re-opened this. Thank you.

[kazk]

Looks like it was overlooked because it should fall back to KUBECONFIG as long as the following files doesn't exist:

• /var/run/secrets/kubernetes.io/serviceaccount/token
• /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
• /var/run/secrets/kubernetes.io/serviceaccount/namespace

Failing to find these files should fall back to KUBECONFIG.

[kazk]

@webern Do you have the files listed above when you're outside the cluster?

[webern]

No I don't have those files outside of the cluster. Outside of the cluster I'm running on a mac. I think the check for rustls happens too early in the code... before the check for those files.

$ ls /var/run/secrets/kubernetes.io/
ls: /var/run/secrets/kubernetes.io/: No such file or directory

[kazk]

Hmm, then it should fall back to KUBECONFIG because from_cluster_env should fail without those files.

https://github.com/kube-rs/kube-rs/blob/b7fe7485a5661bdec398377109801e675db8aaee/kube/src/config/mod.rs#L70-L75

I'm assuming you're using Config::infer or Client::try_default which uses Config::infer.

[webern]

Client::try_default correct.

from_cluster_env succeeds returning the hardcoded workaround url irrespective of whether we are in cluster or not:
https://github.com/kube-rs/kube-rs/blob/master/kube/src/config/mod.rs#L94...L97

[kazk]

You're correct about cluster_url, but from_cluster_env will fail when reading those files just below.

https://github.com/kube-rs/kube-rs/blob/b7fe7485a5661bdec398377109801e675db8aaee/kube/src/config/mod.rs#L107-L115

[webern]

Oh I see. This issue might be in error. I'll double check through my breakpoints again.

[webern]

I think I was wrong about the failure mode. Perhaps it was getting my kubeconfig and failing because it had the server address 127.0.0.1. Closing.