Client doesn't honor tls-server-name setting in kubeconfig

[rw-nicholas]

What happened (please include outputs or screenshots):

Tried to connect to my cluster with a utility that uses your library. As far as I can tell, the utility's code is correct and the k8s-client python code does not honor the tls-server-name and propagate it down the stack to urllib3.

Received this exception:

Traceback (most recent call last):
  File "/home/nicholas/code/k8spurger-venv/lib/python3.9/site-packages/urllib3/connectionpool.
py", line 703, in urlopen
    httplib_response = self._make_request(
  File "/home/nicholas/code/k8spurger-venv/lib/python3.9/site-packages/urllib3/connectionpool.
py", line 386, in _make_request
    self._validate_conn(conn)
  File "/home/nicholas/code/k8spurger-venv/lib/python3.9/site-packages/urllib3/connectionpool.
py", line 1042, in _validate_conn
    conn.connect()
  File "/home/nicholas/code/k8spurger-venv/lib/python3.9/site-packages/urllib3/connection.py",
 line 467, in connect
    _match_hostname(cert, self.assert_hostname or server_hostname)
  File "/home/nicholas/code/k8spurger-venv/lib/python3.9/site-packages/urllib3/connection.py",
 line 540, in _match_hostname
    match_hostname(cert, asserted_hostname)
  File "/home/nicholas/code/k8spurger-venv/lib/python3.9/site-packages/urllib3/util/ssl_match_
hostname.py", line 150, in match_hostname
    raise CertificateError(
urllib3.util.ssl_match_hostname.CertificateError: hostname 'CNAME-THAT-I-USE' doesn
't match either of 'LIST', 'OF', 'OTHER', 'NAMES'

This is explicitly why I set tls-server-name in my kubeconfig.

What you expected to happen:

TLS connection to my cluster, with the proper SNI sent.

How to reproduce it (as minimally and precisely as possible):

Set your cluster.server property to some IP/CNAME not in the cert. Set tls-server-name in kubeconfig correctly.

Anything else we need to know?:

Looks like it is pretty easy to support. Just need to change https://github.com/kubernetes-client/python/blob/master/kubernetes/base/config/kube_config.py#L544 to read the tls-server-name, and make sure that gets propagated to https://github.com/kubernetes-client/python/blob/master/kubernetes/client/rest.py#L73 as assert_hostname

[yliaog]

/assign

[yliaog]

do you mind to send a PR? Thanks.

[rw-nicholas]

Unfortunately, there are lots of hoops to jump through (CLA, tests, company OSS policy that's non-existent, etc) and I am not really a pythonista. This is why I pointed to what I think are the right spots in code base. Also, it seems the client/rest.py is part of the generated code, so not entirely sure how that should be patched (hopefully not yet another rest_client_patch.diff) and I am not really inclined to chase down how to do it correctly.

Best of luck in getting this fixed.

[goodspark]

Adding a +1. I'm using a kubeconfig with a tls-server-name that's different from the cluster hostname.

I wound up hacking this in a fork bc I also don't know what the process is to get the OpenAPI schema updated and clients regenerated.

This is the crux of the fix, but obviously it needs to plumbed through the configuration object.
goodspark@83155eb

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[midopa]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[goodspark]

/remove-lifecycle rotten