When the REQUESTS_CA_BUNDLE environment variable is set, pykube is unable to connect to a server:
File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", line 601, in urlopen
chunked=chunked)
File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", line 346, in _make_request
self._validate_conn(conn)
File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", line 850, in _validate_conn
conn.connect()
File "/usr/lib/python3.6/site-packages/urllib3/connection.py", line 326, in connect
ssl_context=context)
File "/usr/lib/python3.6/site-packages/urllib3/util/ssl_.py", line 329, in ssl_wrap_socket
return context.wrap_socket(sock, server_hostname=server_hostname)
File "/usr/lib/python3.6/ssl.py", line 407, in wrap_socket
_context=self, _session=session)
File "/usr/lib/python3.6/ssl.py", line 814, in __init__
self.do_handshake()
File "/usr/lib/python3.6/ssl.py", line 1068, in do_handshake
self._sslobj.do_handshake()
File "/usr/lib/python3.6/ssl.py", line 689, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:777)
It appears that this is because the session object of the HTTPClient doesn't play nice when REQUESTS_CA_BUNDLE is set. This is apparently a known issue in requests, and it doesn't look like there's an ETA for a fix (they're pushing it off to v3.0.0):
This might be able to be worked around for now by adding the verify argument to kwargs in HTTPClient.get_kwargs. I'll investigate further and open a PR if that's the case
Never mind, I see this is already fixed in master. If anyone else comes across this issue, you can work around it (at least temporarily) by installing pykube>=0.16a1.
When the
REQUESTS_CA_BUNDLE
environment variable is set, pykube is unable to connect to a server:It appears that this is because the
session
object of theHTTPClient
doesn't play nice when REQUESTS_CA_BUNDLE is set. This is apparently a known issue inrequests
, and it doesn't look like there's an ETA for a fix (they're pushing it off to v3.0.0):https://github.com/requests/requests/issues/3829
I can confirm this is the case by passing the
verify
argument to theget
method:This might be able to be worked around for now by adding the
verify
argument to kwargs inHTTPClient.get_kwargs
. I'll investigate further and open a PR if that's the case