Hi,
We are running a Kubernetes cluster that uses an intermediate certificate as the default CA across all components. This setup generally works fine, but we run into SSL verification issues with Python-based applications — such as Airflow, as discussed here — due to how urllib3 and related libraries handle CA certificates.
Problem
Python’s urllib3 doesn’t support validating certs when only an intermediate CA is available — it expects a full chain certificate. Kubernetes components by default place the CA cert (in our case, the intermediate only) at /etc/kubernetes/pki/ca.crt, which gets mounted into pods via the kubernetes secret volume.
As a workaround, we replaced the default ca.crt file on our control plane nodes with the full cert chain (root + intermediate), then restarted the controller-manager. This causes the updated cert chain to be mounted into pods via the kubernetes service account token volume at:
/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
This solves the problem for Python apps — they can now validate HTTPS connections to the api-server using the complete chain.
Concern
We’ve seen community warnings about modifying ca.crt post-installation. Some Go libraries (used by kubelet, etc.) may not support full cert chains and could behave incorrectly — e.g., failing to parse the CA chain or trusting only the root CA.
So our actual question is:
Can we:
- Leave the default
ca.crt(intermediate-only) in place for all cluster components - Place a second CA chain file (full root+intermediate) on the control plane nodes,
- Patch the controller-manager manifest to mount that alternate chain file and pass it into pods (so only Python-based apps use it)?
Has anyone tried this approach? Could it break something, or does it seem safe in your experience?
Thanks in advance!