Fix secrets not masked in Rendered Templates view with KubernetesPodOperator

[juan-pablo-guereca]

Regression fix, restores Airflow 2 behavior, adds nothing new.

When var.json is used in a Jinja template (e.g. to pass secrets as env vars to a KubernetesPodOperator), _get_variable deserialised the JSON before masking. The isinstance(var_val, str) guard evaluated to False for the resulting dict, so mask_secret was never called. The secret was stored unredacted in the rendered_task_instance_fields table and shown as plain text in the Rendered Templates view.

Both the SecretCache hit path and the secrets-backend path receive the same fix.

---

Before the fix:

After the fix:

DAG to reproduce it:

from airflow import DAG
from airflow.operators.bash import BashOperator
from airflow.providers.cncf.kubernetes.operators.pod import (
    KubernetesPodOperator,
)

DAG_ID = "test_secrets_masking"

ENVS = {
    "some_password": "{{ var.value.some_password }}",
    "some_password_json": "{{ var.json.some_password }}",
    "some_password_json.secret": "{{ var.json.some_password.secret }}",
    "some_password_json.foo": "{{ var.json.some_password.foo }}",
}

with DAG(
    dag_id=DAG_ID,
    schedule=None,
    description="just a dummy dag to test secrets masking",
    max_active_runs=1,
):
    command = "echo hi there; env; echo bye"

    BashOperator(task_id="some_bash_pod_operator", bash_command=command, env=ENVS)

    KubernetesPodOperator(
        task_id="some_k8s_pod_operator",
        cmds=["/bin/bash", "-c", command],
        env_vars=ENVS,
        is_delete_operator_pod=True,
        in_cluster=True,
        get_logs=True,
    )

Fixes the issue #69021

---

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

• Yes, claude

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example Dag that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[SameerMesiah97]

Just 2 missing test cases. CI needs to be triggered. Looks good otherwise.

[SameerMesiah97]

Resolve the comment please. Looks good.

edit: Just saw CI needs to be triggered. Approved pending green CI.

[potiuk]

It's an interesting one - I am not sure if we want to merge this one. This gives false sense of security - you know you are not supposed to pass secrets in K8S Pod Operator Env Vars ?

Never use environment variables to pass secrets (for example connection authentication information) to Kubernetes Pod Operator. Such environment variables will be visible to anyone who has access to see and describe PODs in Kubernetes. Instead, pass your secrets via native Kubernetes Secrets or use Connections and Variables from Airflow. For the latter, you need to have apache-airflow package installed in your image in the same version as Airflow you run your Kubernetes Pod Operator from).

Reference

I will psss that to the security team for consideration - but I think this one - especially that it addresses something we explicitly told is a bad practice is not a good idea

[shahar1]

Blocking until figuring out the above

[juan-pablo-guereca]

@potiuk totally agree passing secrets via pod env vars isn't safe practice, and this doesn't change that guidance at all, k8s level visibility stays the same either way.

The reason I'd still love to see this merged: this masking already works fine in Airflow 2. In AF3 it quietly stopped working for var.json values in some cases, so this is really just restoring existing behavior, not adding anything new. I worry that teams who tested and trusted this on AF2 might not realize it's silently different on AF3.

One more bit of context in case it's useful: I'm working on an AF2 to AF3 migration with a lot of existing DAGs, some of which already use this pattern (not by choice, just the reality of a large existing codebase). Losing masking silently on upgrade is a real regression for that kind of migration, not just a hypothetical, but happy to defer to whatever the security team decides either way.

[potiuk]

OK. I think if it eases the migration we can release it . @shahar1 ?

[boring-cyborg]

Awesome work, congrats on your first merged pull request! You are invited to check our Issue Tracker for additional contributions.