Add skipKubernetesEnvVars option for all components in chart to prevent env var conflicts and UI exposure

[uplsh580]

Related PR

• Related Issue: AIRFLOW__API__EXPOSE_CONFIG when set to 'non-sensitive-only' is exposing some secrets #60668
• This addresses concerns raised in PR Remove automatic KUBERNETES_ENVIRONMENT_VARIABLES and KUBERNETES_SECRETS prefixes from chart helpers #60750 by providing a non-breaking alternative.

Summary

This PR adds the skipKubernetesEnvVars option to all Airflow components (workers, scheduler, apiServer, webserver, triggerer, dagProcessor, flower, cleanup, databaseCleanup, createUserJob) as an alternative solution to address the breaking change introduced in PR #60750.

Problem

When using KubernetesExecutor, Airflow automatically creates AIRFLOW__KUBERNETES_ENVIRONMENT_VARIABLES__ prefixed environment variables for each env var defined in component-specific env arrays (e.g., workers.env, scheduler.env, apiServer.env). These automatically generated environment variables are exposed in the Airflow web UI config page, which poses a security risk when env vars contain sensitive information such as API keys, passwords, or tokens (Like below image).

Additionally, this automatic behavior can cause unexpected conflicts. When users add environment variables to component-specific arrays like scheduler.env, they expect those variables to only apply to the scheduler component. However, the automatically generated AIRFLOW__KUBERNETES_ENVIRONMENT_VARIABLES__ prefixed variables are propagated to worker pods created by KubernetesExecutor, potentially causing conflicts or unintended behavior when the same variable names exist in different components.

Solution

This PR introduces a skipKubernetesEnvVars boolean option (default: false) for each component that allows users to prevent the automatic creation of these prefixed env vars. When set to true, sensitive values will not be exposed in the UI while maintaining backward compatibility.

For users who still need AIRFLOW__KUBERNETES_ENVIRONMENT_VARIABLES__ prefixed env vars for KubernetesExecutor task pods, they can use:

• The top-level env configuration, or
• The config.kubernetes_environment_variables section

instead of component-specific env arrays.

Changes

• Added skipKubernetesEnvVars option and comprehensive documentation to values.yaml for all components
• Added skipKubernetesEnvVars schema definitions to values.schema.json for all components

Backward Compatibility

The default value is false, ensuring backward compatibility with existing deployments. Users must explicitly set skipKubernetesEnvVars: true to enable this security feature.

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)
• Cursor

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[jscheffl]

@jedcunningham I am not sure about why this option actually was made - is there a historc reason you are aware or a need in a specific deployment condition?

If this is changed like proposed - and in general this makes sense - will this be a breaking change we need to postpone into a version 2.0 which we are planning and take the option to wipe this in general?

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 5 days if no further activity occurs. Thank you for your contributions.

[jscheffl]

un-stale this PR to mark it as reminder to drop this feature in geneal in Helm Chart 2.0 (proposal)

[jedcunningham]

I'm pretty sure this was for pre-pod-template-file KE. In which case, we can drop it now even.

[jscheffl]

I'm pretty sure this was for pre-pod-template-file KE. In which case, we can drop it now even.

@jedcunningham then I'd propose to re-vitalize PR #60750 which was there before which proposes to nuke these variables. Initially tagged this as 2.0 but if okay for you and actually not used then we should make this in 1.20. - WDYT?

[potiuk]

@uplsh580 This PR has been converted to draft because it does not yet meet our Pull Request quality criteria.

Issues found:

• ❌ Merge conflicts: This PR has merge conflicts with the main branch. Your branch is 1868 commits behind main. Please rebase your branch (git fetch origin && git rebase origin/main), resolve the conflicts, and push again. See contributing quick start.

Note: Your branch is 1868 commits behind main. Some check failures may be caused by changes in the base branch rather than by your PR. Please rebase your branch and push again to get up-to-date CI results.

What to do next:

• The comment informs you what you need to do.
• Fix each issue, then mark the PR as "Ready for review" in the GitHub UI - but only after making sure that all the issues are fixed.
• There is no rush — take your time and work at your own pace. We appreciate your contribution and are happy to wait for updates.
• Maintainers will then proceed with a normal review.

Converting a PR to draft is not a rejection — it is an invitation to bring the PR up to the project's standards so that maintainer review time is spent productively. There is no rush — take your time and work at your own pace. We appreciate your contribution and are happy to wait for updates. If you have questions, feel free to ask on the Airflow Slack.

---

Note: This comment was drafted by an AI-assisted triage tool and may contain mistakes. Once you have addressed the points above, an Apache Airflow maintainer — a real person — will take the next look at your PR. We use this two-stage triage process so that our maintainers' limited time is spent where it matters most: the conversation with you.

[uplsh580]

Resolved by #60750