Avoid caching kubeconfig for exec-based auth in AsyncKubernetesHook

[Codingaditya17]

What does this PR do?

Prevents caching Kubernetes kubeconfig in AsyncKubernetesHook when exec-based
authentication is used. Exec auth plugins (e.g. EKS, GKE) return short-lived
credentials which may expire during deferrable task execution if cached.

Why is this needed?

Deferrable Kubernetes tasks reuse the async hook across awaits. Caching kubeconfig
in this case can lead to expired credentials and authentication failures.

Related issues

• Fixes AsyncKubernetesHook._config_loaded caching breaks exec-based auth token refresh in KubernetesPodTrigger #61737

[shahar1]

@Codingaditya17 could you please fix static checks?

[SameerMesiah97]

This fix should work but I do not think this is scoped to exec-based auth only as communicated in the PR description. It appears that you are removing caching entirely, which is a bit too blunt. Now, caching for _load_config was very recently introduced in cncf.kubernertes 10.12.3 so I woud not consider this a regression of historical behavior but this will result in log spam when using def watch_pod_events.

@shahar1

I see that you have approved this PR. If you see the resolution of issue #61737 as urgent, then I believe it should be merged as is (with a #TODO and a prompt follow-up PR) but if we have time, we should try to refine the implementation so that it does not bluntly remove caching and thereby cause another regression.

[Codingaditya17]

Thanks for the detailed feedback.

I agree the current approach is blunt, and that an expiry-aware or exec-specific solution would be better long-term. Given the active breakage with exec-based auth, I prioritized correctness first to unblock users.

I’ll fix the failing static checks shortly.

Once CI is green, I’m happy to either:

• add a TODO here and follow up with a refined PR, or
• update this PR to scope caching only to non-exec auth.

Please let me know which direction you’d prefer.

[shahar1]

Thanks for the detailed feedback.

I agree the current approach is blunt, and that an expiry-aware or exec-specific solution would be better long-term. Given the active breakage with exec-based auth, I prioritized correctness first to unblock users.

I’ll fix the failing static checks shortly.

Once CI is green, I’m happy to either:

• add a TODO here and follow up with a refined PR, or
• update this PR to scope caching only to non-exec auth.

Please let me know which direction you’d prefer.

If you could scope caching only to non-exec auth I think it would be the optimal compromise for now.
Later you could implement a long-term solution.

Please be aware that I'm starting to cut the release in few minutes for all providers altogether, so I'm not sure that it will make it to the upcoming release - but if the other maintainers find this PR critical to merge during the voting period, we could postpone k8s release, and do it ad-hoc (on demand) afertwards. Feel free to comment in the dev list thread, and in the GitHub issue about that during the period of time.

[Codingaditya17]

Thanks for the clarification.

That makes sense . I’ll update this PR to scope caching only to non-exec auth, and keep the behavior unchanged for other cases. I’ll push an update shortly.

Understood about the provider release timing as well.

[Codingaditya17]

The latest commit fixes the remaining ruff/static issues.
Once workflows are approved, CI should pass on the current HEAD.