Duo-ee commented on issue #53192: URL: https://github.com/apache/airflow/issues/53192#issuecomment-6460095277
For anyone landing here from the "is this still outstanding" question: it is, and I traced where it actually breaks. Two things that may save someone a day. **Where the CA goes missing.** Not in the launched pod — it is the worker's own Kubernetes client that fails TLS while listing pods for `KubernetesPodOperator`. `KubernetesHook.__init__` takes `client_configuration`, `in_cluster`, `config_file`, `config_dict`, `disable_verify_ssl` and no CA parameter at all, and none of the five branches in `get_conn()` sets `Configuration.ssl_ca_cert`. The executor side does have one: `[kubernetes_executor] ssl_ca_cert` is read in `kube_client.py`'s `get_kube_client()`, which the task-side hook never goes through. That asymmetry is the bug. **What works today, and one workaround that does not.** Putting a CA into an explicit `client.Configuration` and handing it to the hook does *not* survive: every `config.load_kube_config(..., client_configuration=...)` / `load_incluster_config(...)` call ends with `KubeConfigLoader._set_config()`, which blind-copies `ssl_ca_cert` from the kubeconfig — `None` when the kubeconfig has no `certificate-authority`, so your value is silently reset. The published one therefore has to be on the kubeconfig itself: `certificate-authority-data` (full chain, PEM, base64) on the cluster entry, supplied through the connection's `kube_config` extra (with `in_cluster: false`), `kube_config_path`, or the operator's `config_file`. That path ends with `Configuration.ssl_ca_cert` set to exactly the value you wrote, on every branch. In-cluster is the exception — there the client always reads the service-account CA, so a kubeconfig only helps if you also leave in-cluster mode. **On the history.** #55403 (inherit the executor value into the operator) was closed by the stale bot with no human review. #71831 (mirror `ssl_ca_cert` into `KubernetesHook`) was the closest complete implementation and was closed as part of the open-PR-limit cleanup, not on technical grounds. #73942 only set `REQUESTS_CA_BUNDLE`/`SSL_CERT_FILE` inside the launched pod, which is a level below the failure kaxil described. So none of the three was rejected on design — the hook simply still has no place to put a CA. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
