Duo-ee commented on issue #53192: URL: https://github.com/apache/airflow/issues/53192#issuecomment-6461141371
A correction to my own comment above, because one sentence in it is wrong and it is the sentence someone would act on. I wrote that an explicit `client.Configuration` handed to the hook never survives, because every loader path ends in `KubeConfigLoader._set_config()`. Re-running the harness against the current `main` copy of `hooks/kubernetes.py` (sha `b4809db6`) shows that is true for four routes and false for the fifth: | route selected | loader call | explicit `Configuration.ssl_ca_cert` | | --- | --- | --- | | `in_cluster: true` (`hooks/kubernetes.py:286`) | `config.load_incluster_config()` — no `client_configuration` passed | **survives**; the hook hands your object straight to `_TimeoutK8sApiClient` at `:288`, the in-cluster loader only fills in a fresh default configuration | | `kube_config_path` (`:296`) | `load_kube_config(..., client_configuration=...)` | overwritten — `None` when the kubeconfig has no `certificate-authority` | | connection extra `kube_config` (`:315`) | same | overwritten | | `config_dict` (`:329`) | `load_kube_config_from_dict(..., client_configuration=...)` | overwritten | | nothing selected → `_get_default_client` (`:358`, `:363`) | both loaders are given `client_configuration=` | overwritten | So the two workarounds split by route rather than one being dead everywhere: with `in_cluster: true` the explicit-`Configuration` route does carry your CA (it is the only route where it does), and a kubeconfig-carried CA does not apply there unless you also leave in-cluster mode; with any kubeconfig-shaped route it is the other way round. My line about in-cluster "always reading the service-account CA" describes the configuration the loader builds for itself, not one you pass in. How that was checked, so the limits are clear: an offline harness, not a cluster. It loads a pinned `main` copy of `hooks/kubernetes.py` (`b4809db6cf36747adca9e5c9ccd92343bcc28b83`), stubs the `airflow.*` imports, and calls the real `KubernetesHook.get_conn()` with `SERVICE_TOKEN_FILENAME`/`SERVICE_CERT_FILENAME` and `KUBERNETES_SERVICE_HOST`/`PORT` aimed at temp files. Five cases, kubernetes client 33.1.0, Python 3.10.11. It measures how the configuration object is assembled before the client is built — no TLS handshake, and `_set_config` was not re-checked on older `kubernetes` releases. For whoever picks this up, the remaining gap is unchanged: `KubernetesHook.__init__` still has no CA parameter, so both workarounds need subclassing `KubernetesPodOperator` to inject a configuration. Whether the fix belongs there (a `ca_cert` argument, as in #71831) or should instead reuse `kube_client.get_kube_client()` and `[kubernetes_executor] ssl_ca_cert` is a design question the history does not answer — #71831 was closed by the open-PR-count cleanup, not on technical grounds. The async hook has the same clobbering in every route (`:952`, `:961`, `:977`, `:1012`, `:1031` all pass `client_configuration=`), and it does not expose `disable_verify_ssl` at all. -- 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]
