AIRFLOW__API__EXPOSE_CONFIG when set to 'non-sensitive-only' is exposing some secrets

[anavrotski]

Apache Airflow version

3.1.6

If "Other Airflow 3 version" selected, which one?

3.1.0

What happened?

When the enivronment variable AIRFLOW__API__EXPOSE_CONFIG is set to non-sensitive-only some secrets are visible in menu Admin / Config:

Section								Key							Value
core								simple_auth_manager_users	admin:admin  <- USER:PASSWORD
core								sql_alchemy_conn			mysql+mysqldb://DB_USER:DB_PASSWORD_HERE@....rds.amazonaws.com:3306/airflow_db
kubernetes_environment_variables	client_id					some_uuid    <- probably shouldn't be exposed
kubernetes_environment_variables	client_secret				some_secret  <- probably shouldn't be exposed

What you think should happen instead?

Values from above should not be visible.

How to reproduce

Set AIRFLOW__API__EXPOSE_CONFIG env var to 'non-sensitive-only'.

Operating System

linux

Versions of Apache Airflow Providers

No response

Deployment

Official Apache Airflow Helm Chart

Deployment details

Chart 1.18

Anything else?

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[uplsh580]

I’m interested in fixing this. May I be assigned to this issue?

[uplsh580]

Discussion 1 - core.simple_auth_manager_users

core.simple_auth_manager_users doesn't seem to be sensitive information as it primarily consists of roles and user lists rather than credentials
Ref: https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html#simple-auth-manager-users

[uplsh580]

Discussion 2 - core.sql_alchemy_conn

The core.sql_alchemy_conn in the deprecated section is missing the sensitive masking, even though it's already handled in the database section.

To address this, I suggest removing the redundant exposure in the deprecated section. I've opened a PR for this, but please feel free to share your feedback as I'm open to any better approaches.

Related PR: #60713

[uplsh580]

Discussion 3 - kubernetes_environment_variables

kubernetes_environment_variables	client_id					some_uuid    <- probably shouldn't be exposed
kubernetes_environment_variables	client_secret				some_secret  <- probably shouldn't be exposed

According to the official Airflow documentation, passing secrets via environment variables is considered bad practice. Since users are encouraged to use Kubernetes Secrets or Airflow Connections for sensitive data, I believe kubernetes_environment_variables should not ideally contain sensitive information that requires masking.

NOT masking when using environment variables

When you are using some operators - for example airflow.providers.cncf.kubernetes.operators.pod.KubernetesPodOperator, you might be tempted to pass secrets via environment variables. This is very bad practice because the environment variables are visible to anyone who has access to see the environment of the process - such secrets passed by environment variables will NOT be masked by Airflow.

If you need to pass secrets to the KubernetesPodOperator, you should use native Kubernetes secrets or use Airflow Connection or Variables to retrieve the secrets dynamically.

[anavrotski]

I did not set that client_id and client_secret in the helm chart, or somewhere in secrets or connections.

[anavrotski]

Discussion 1 - core.simple_auth_manager_users

core.simple_auth_manager_users doesn't seem to be sensitive information as it primarily consists of roles and user lists rather than credentials Ref: https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html#simple-auth-manager-users

If it is a role, not password - masking really not needed.

[uplsh580]

I did not set that client_id and client_secret in the helm chart, or somewhere in secrets or connections.

@anavrotski
Aren't you using AIRFLOW__KUBERNETES_ENVIRONMENT_VARIABLES__{{ key }} env variables for these configurations?

like...

• AIRFLOW__KUBERNETES_ENVIRONMENT_VARIABLES__CLIENT_ID
• AIRFLOW__KUBERNETES_ENVIRONMENT_VARIABLES__CLIENT_SECRET

[anavrotski]

I did not set that client_id and client_secret in the helm chart, or somewhere in secrets or connections.

@anavrotski Aren't you using AIRFLOW__KUBERNETES_ENVIRONMENT_VARIABLES__{{ key }} env variables for these configurations?

like...

• AIRFLOW__KUBERNETES_ENVIRONMENT_VARIABLES__CLIENT_ID
• AIRFLOW__KUBERNETES_ENVIRONMENT_VARIABLES__CLIENT_SECRET

It looks like these variables were somehow taken from the custom OAuth configuration. I can see them in k8s pods, but I can not see them anywhere in the Helm chart.

[uplsh580]

@anavrotski
In my setup (apache/airflow:3.1.6 image + Airflow Helm Chart 1.18.0), those variables are not present.
Could you check if you are using a extended or custom Docker image? They might be baked into the image itself.