Uh oh!
There was an error while loading. Please reload this page.
Masking configuration values irrelevant to DAG author - #43040
Conversation
Uh oh!
There was an error while loading. Please reload this page.
potiuk
commented
Oct 15, 2024
Just adding a unit test, and I think it's ready to go :) |
amoghrajesh
commented
Oct 16, 2024
Struggling with some test related setup. I am running into this as of now: I see some discussions around, does anyone have any suggestions for this? I use Pycharm |
potiuk
commented
Oct 16, 2024
I believe (I have not yet had time to look at it) this requires to use I guess those should be updated ?
|
potiuk
commented
Oct 16, 2024
I think we generally should provide rather comprehensive guide (at least with some links) to our contributors how to setup the venv now (Breeze is covered because it uses workspace installation internally I believe)? Am I right @ashb ? |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Breeze is all set up yes. UV workspace isn't 100% required yet (though I don't think anyone tested running tests from inside pycharm), but for pycharm to find imports you need to set up some paths as the right kind of folder in the UI I'm not a pycharm user, but @kaxil@dstandish can provide some insight. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
#42951 should help Pycharm too. Remaining "manual" steps as pycharm user are:
|
amoghrajesh
commented
Oct 16, 2024
I just pulled in #42951, it doesn't seem to fix it for me. I still keep getting |
dstandish
commented
Oct 16, 2024
Anything in particular you wanted me to look at? |
amoghrajesh
commented
Oct 16, 2024
@ashb@potiuk@kaxil I changed the logic to incorporate what was suggested above. Now I am able to get this result: From my original list, these aren't masked: As per the comments above, looks like I think:
Are ok to be unmasked. That leaves us with: Should these be masked or its alright to keep them unmasked? |
ashb
commented
Oct 16, 2024
|
amoghrajesh
commented
Oct 16, 2024
Okay, in that case, this should be ok |
kaxil
commented
Oct 16, 2024
Fixed in #43082 |
amoghrajesh
commented
Oct 22, 2024
@ashb does it look good to go? Got a green CI |
potiuk
commented
Oct 23, 2024
Looks like all the comments are resolved and address by @amoghrajesh . LGTM. @kaxil@ashb - are you ok with merging it? |
ashb
commented
Oct 23, 2024
Some configurations are irrelevant to DAG authors and hence we need to mask those to avoid it from getting logged unknowingly. Co-authored-by: adesai <adesai@cloudera.com> Co-authored-by: Ash Berlin-Taylor <ash_github@firemirror.com>
kaxil
commented
Oct 23, 2024
This change has caused the |
kaxil
commented
Oct 23, 2024
Fix here: #43335 |
Some configurations are irrelevant to DAG authors and hence we need to mask those to avoid it from getting logged unknowingly. Co-authored-by: adesai <adesai@cloudera.com> Co-authored-by: Ash Berlin-Taylor <ash_github@firemirror.com> (cherry picked from commit 0b030c5)
Some configurations are irrelevant to DAG authors and hence we need to mask those to avoid it from getting logged unknowingly. Co-authored-by: adesai <adesai@cloudera.com> Co-authored-by: Ash Berlin-Taylor <ash_github@firemirror.com> (cherry picked from commit 0b030c5) Co-authored-by: Amogh Desai <amoghrajesh1999@gmail.com>
Some configurations are irrelevant to DAG authors and hence we need to mask those to avoid it from getting logged unknowingly. Co-authored-by: adesai <adesai@cloudera.com> Co-authored-by: Ash Berlin-Taylor <ash_github@firemirror.com>
saurabhb-dev
commented
Oct 24, 2024
@amoghrajesh , shouldn't the list of sensitive_config_values be updated with the list of keys that need to redact ? |
potiuk
commented
Oct 24, 2024
Not really @saurabhb-dev , It's even better to mask values in this case, rather than keys. The secrets_masker works in two modes:
This is what happens here - we retrieve all the secret config values (whether they come by env vars or by other means) and we add values (i.e. actual secrets) to be masked. This way when any secret is printed anywhere where secrets_masker is used, it will automatically mask it - regardless if it is a structure (secrets_masker checks values of dicts for example) or whether it's already converted to string. |
Some configurations are irrelevant to DAG authors and hence we need to mask those to avoid it from getting logged unknowingly. Co-authored-by: adesai <adesai@cloudera.com> Co-authored-by: Ash Berlin-Taylor <ash_github@firemirror.com> (cherry picked from commit 0b030c5) Co-authored-by: Amogh Desai <amoghrajesh1999@gmail.com>
figure i'd ask here before creating a new issue airflow/airflow/configuration.py Lines 857 to 859 in c99887e
hence the which is a bit confusing since i removed all references to |
amoghrajesh
commented
Nov 7, 2024
@zachliu we do not return ('database', 'sql_alchemy_conn') as part of self.sensitive_config_values. Here are the sensitive values: https://github.com/amoghrajesh/airflow/blob/840ea3efb9533837e9f36b75fa527a0fbafeb23a/airflow/configuration.py#L122-L129 The warning comes from configuration.py#919 |
zachliu
commented
Nov 7, 2024
@amoghrajesh i beg to differ
|
zachliu
commented
Nov 7, 2024
amoghrajesh
commented
Nov 7, 2024
@zachliu from the PR it doesnt look like it was targetted for 2.10.3. |
zachliu
commented
Nov 7, 2024
I created a new issue to track this: #43794 |
Some configurations are irrelevant to DAG authors and hence we need to mask those to avoid it from getting logged unknowingly. Co-authored-by: adesai <adesai@cloudera.com> Co-authored-by: Ash Berlin-Taylor <ash_github@firemirror.com>
Airflow did not register the configured sensitive_config_values with the secrets masker, so sensitive values from airflow.cfg (e.g. secret_key, fernet_key, broker/result-backend URLs with credentials) could appear unredacted in task logs a DAG author can read. Backport of the net change in upstream commit 0b030c5 (apache#43040, fixed in 2.10.3): add AirflowConfigParser.mask_secrets(), which feeds every sensitive_config_values entry to mask_secret(), and call conf.mask_secrets() from settings.initialize() (placed after configure_action_logging(), as 2.8.1 predates run_providers_custom_runtime_checks). Additive, low regression risk. Registered in odp/patch_files.txt. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Airflow did not register the configured sensitive_config_values with the secrets masker, so sensitive values from airflow.cfg (e.g. secret_key, fernet_key, broker/result-backend URLs with credentials) could appear unredacted in task logs a DAG author can read. Backport of the net change in upstream commit 0b030c5 (apache#43040, fixed in 2.10.3): add AirflowConfigParser.mask_secrets(), which feeds every sensitive_config_values entry to mask_secret(), and call conf.mask_secrets() from settings.initialize() (placed after configure_action_logging(), as 2.8.1 predates run_providers_custom_runtime_checks). Additive, low regression risk. Registered in odp/patch_files.txt. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Some configurations are irrelevant to DAG authors and hence we need to mask those to avoid it from getting logged unknowingly.
^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named
{pr_number}.significant.rstor{issue_number}.significant.rst, in newsfragments.