You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Webserver doesn't mask rendered fields for pending tasks #22738
Thanks, MASK_SECRETS_IN_LOGS should be set for masking of secret to work. It is set automatically when airflow tasks run is called. The sequential scheduler I use for local testing internally calls the airflow tasks run command to run tasks and thus I was confused over how masking is done when task is executed though the taskinstance.py file had not set the variable. I left a note in the PR over whether we should enable this just during rendering the task template in UI.
I'm still seing unmasked values for secrets on the rendered section for a pending task, once it runs the values get masked. In my case this is happening in the environment field of a docker operator. I don't know if the problem happens only because it's a different field, maybe the tests for this should be extended.
@hugochinchilla I believe you need to store your secret in an Airflow variable or connection and then use jinja to render it in your MY_VARIABLE value in order to take advantage of secrets masking. Not sure this works for hard-coded values.
Also secrets should not be hard-coded or loaded during DAG parsing (more in Airflow Best Practices).
Actually this is a simplification, the problem I'm having is actually using data inside a Connection, but that connection is serialized as base64 in a factory that creates the operators, the code calls mask_secret() but the value is exposed until the task actually runs.
I've mitigated it creating a macro to call mask_secret() and return the value, so I can use something like {{ macros.plugin_name.mask_secret(some_secret) }} and the value is masked even when the task is pending.
Activity
tirkarthi commentedon Apr 5, 2022
I have created #22754 as a fix. Can you please confirm if
MASK_SECRETS_IN_LOGSis enabled in your settings?m1racoli commentedon Apr 5, 2022
I am not sure that variable is intended to be user configurable. But HIDE_SENSITIVE_VAR_CONN_FIELDS is set to
Trueas per Airflow config reference.tirkarthi commentedon Apr 5, 2022
Thanks,
MASK_SECRETS_IN_LOGSshould be set for masking of secret to work. It is set automatically whenairflow tasks runis called. The sequential scheduler I use for local testing internally calls theairflow tasks runcommand to run tasks and thus I was confused over how masking is done when task is executed though the taskinstance.py file had not set the variable. I left a note in the PR over whether we should enable this just during rendering the task template in UI.#22754 (comment)
Mask sensitive values for not-yet-running TIs (#23807)
Mask sensitive values for not-yet-running TIs (#23807)
pull master (#25)
hugochinchilla commentedon Oct 20, 2022
I'm still seing unmasked values for secrets on the rendered section for a pending task, once it runs the values get masked. In my case this is happening in the environment field of a docker operator. I don't know if the problem happens only because it's a different field, maybe the tests for this should be extended.
I'm using Airflow 2.3.4
hugochinchilla commentedon Oct 20, 2022
Here is an example on how the issue can still be reproduced:
m1racoli commentedon Oct 21, 2022
@hugochinchilla I believe you need to store your secret in an Airflow variable or connection and then use jinja to render it in your
MY_VARIABLEvalue in order to take advantage of secrets masking. Not sure this works for hard-coded values.Also secrets should not be hard-coded or loaded during DAG parsing (more in Airflow Best Practices).
hugochinchilla commentedon Oct 25, 2022
Actually this is a simplification, the problem I'm having is actually using data inside a Connection, but that connection is serialized as base64 in a factory that creates the operators, the code calls
mask_secret()but the value is exposed until the task actually runs.I've mitigated it creating a macro to call
mask_secret()and return the value, so I can use something like{{ macros.plugin_name.mask_secret(some_secret) }}and the value is masked even when the task is pending.