-
Notifications
You must be signed in to change notification settings - Fork 167
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Kubeclient does not support certificate authorities with intermediate certificate #460
Comments
This will load all certificates concatenated in the cacert file, instead of only the first one (ManageIQ#460).
Closing, assuming #461 fixed this. |
Hello, is there an ETA when this fix will be released in the client release? AFAIK it is not in the latest v4.9.2 cc @cben |
Test sandwitches the real CA cert between two other CA certs (another-ca1.pem, another-ca2.pem, simply copied from two runs of update_certs_k0s.rb). Fails before the backport of ManageIQ#461: 1) Failure: KubeclientConfigTest#test_concatenated_ca [/home/beni/kubeclient/test/test_config.rb:196]: Expected false to be truthy. passes with the fix.
Test sandwitches the real CA cert between two unrelated CA certs (another-ca1.pem, another-ca2.pem, simply copied from two runs of update_certs_k0s.rb). No test for root+intermediate scenario. Fails before the backport of ManageIQ#461: KubeclientConfigTest#test_concatenated_ca [/home/beni/kubeclient/test/test_config.rb:196]: Expected false to be truthy. (some experimenting with order suggests only first cert is honored.) Passes with the fix.
Test sandwitches the real CA cert between two unrelated CA certs (another-ca1.pem, another-ca2.pem, simply copied from two runs of update_certs_k0s.rb). No test for root+intermediate scenario. Fails before the backport of ManageIQ#461: KubeclientConfigTest#test_concatenated_ca [/home/beni/kubeclient/test/test_config.rb:196]: Expected false to be truthy. (some experimenting with order suggests only first cert is honored.) Passes with the fix.
reopening:
|
interesting, in lostisland/faraday#371 (opened on faraday but actaully not specific to faraday at all) people had possibly related findings 👀
EDIT: turns out the failure was my mistake, not Mac-specific 🎉. And those discussion of "hashes" IIUC are only interesting for |
Test sandwitches the real CA cert between two unrelated CA certs (another-ca1.pem, another-ca2.pem, simply copied from two runs of update_certs_k0s.rb). No test for root+intermediate scenario. Fails before the backport of ManageIQ#461: KubeclientConfigTest#test_concatenated_ca [/home/beni/kubeclient/test/test_config.rb:196]: Expected false to be truthy. (some experimenting with order suggests only first cert is honored.) Passes with the fix.
The issue
We tried to run a Ruby application (using the kubeclient gem) on a kubernetes cluster which uses a custom CA (the cluster's CA itself is signed by another custom CA, hence the need for intermediate certificates).
Kubeclient (initialized from the KUBECONFIG file) fails with SSL verify errors.
How to reproduce
First, we create a
KUBECONFIG
file in the container by executing the following script:Then we try listing services cluster-wide using the
kubectl
binary:This should work, assuming that the current service account is allowed to list services cluster-wide.
Finally, we try listing the same services in Ruby using
kubeclient
:On clusters where the kubernetes CA has been signed by an intermediate CA, kubeclient fails to verify the kubernetes API certificate, even if the cacert in
/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
contains the intermediate certificates.We see the following stacktrace:
The explanation
The reason of this behavior is the use of
OpenSSL::X509::Store#add_cert
in https://github.com/abonas/kubeclient/blob/v4.9.1/lib/kubeclient/config.rb#L58 .Per the documentation:
If we had used the
add_file
method instead ofadd_cert
every certificate included in the cacert file would have been loaded.Documentation of add_file:
I will submit a PR next
The text was updated successfully, but these errors were encountered: