Does Kubeflow automatically trust the cluster's CA bundle for external HTTPS calls from pipeline components?

Answer

No, Kubeflow Pipelines does not automatically expose the Kubernetes cluster’s CA bundle to pipeline component containers. By default each step trusts only the CA certificates baked into its base image.

Confirmed facts

• The cluster’s CA bundle lives on the node at paths such as /etc/ssl/certs/ca-certificates.crt (or the platform‑specific equivalent).
• Kubeflow Pipelines Operator (v1.4, v1.6, v1.8+, etc.) does not inject that file into the pod’s filesystem unless you explicitly add a volume mount or set an environment variable that points to it.
• If the container’s HTTP client library reads the system trust store (e.g., Python’s requests, Go’s net/http, Node’s TLS stack) and the bundle is made available via SSL_CERT_FILE or the default path, external HTTPS calls will succeed.

Likely explanation

The trust store used by a component is determined by its runtime language and any environment variables such as SSL_CERT_FILE, REQUESTS_CA_BUNDLE, or Java’s javax.net.ssl.trustStore. Since the default launcher image does not mount the host’s CA bundle, those variables are unset, leaving only the image‑bundled certificates.

Steps to make external HTTPS calls trust the cluster CA

1. Mount the host’s CA bundle into the container, for example:

   volumeMounts:
   - name: host-ca
     mountPath: /etc/ssl/certs/ca-certificates.crt
     subPath: ca-certificates.crt
   volumes:
   - name: host-ca
     hostPath:
       path: /etc/ssl/certs/ca-certificates.crt
       type: File
   

2. Ensure the library consults that file. Most libraries will pick up /etc/ssl/certs/ca-certificates.crt automatically; otherwise set an env var, e.g.:

   env:
   - name: SSL_CERT_FILE
     value: /etc/ssl/certs/ca-certificates.crt
   

3. If hostPath mounts are blocked by PSP/OPA, rebuild the component image to include the required CA certificates or create a ConfigMap with the bundle and mount it as a regular volume.

Verification

• Deploy a test step that performs curl -v https://example.com (or an HTTP request in your language) to an external service whose leaf certificate is signed by the cluster’s CA.
• Exec into the pod and confirm the bundle is present: cat /etc/ssl/certs/ca-certificates.crt.
• Compare the pod logs with and without the mount/env var; trust is established only when the bundle is made available.

Note: If your component uses a Java application with a custom keystore or an HTTP library that ignores the system trust store, simply mounting the bundle will not suffice; you must configure the library explicitly. Please let me know the language or HTTP client library used in your pipeline components if you need a more precise recommendation.