potiuk commented on issue #63921: URL: https://github.com/apache/airflow/issues/63921#issuecomment-4104763212
I think this is the part of a better description of our security approach for JWT in 3.1.*. The whole idea is that the values you get are **not** available to you at all. There is a recent change by @ashb that should remove the possibility of reading the env vars from the parent proces by the forked ones: https://github.com/apache/airflow/pull/62523 - going to be implemented in Airflow 3.2.0 And we shoud implement documentation to clearly state that JWT_SECRET, WEB_SERVER_SECRET and other variables should not even be present (because they are not needed) in the workers. Currently we have it mostly as tribal knowledge - not documented, and actually even contradicted by our docs: https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html > Use the same configuration across all the Airflow components. While each component does not require all, some configurations need to be same otherwise they would not work as expected. A good example for that is [secret_key](https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html#config-api-secret-key) which should be same on the Webserver and Worker to allow Webserver to fetch logs from Worker. It's generally been a bit neglected to change our model on that in 3.0.0 and 3.1.1 and inform our users that this is the approach they should take. I have (at latest dev call) volunteered to document it and explain all the "loopholes" and not perfect isolation that current docuementation does not sufficiently describe - for example the fact that DagFileProcessor and Triggerer currently does not provide enough isolation and that DagAuhors can also access the Meta DB configuratiion and that they can still dirctly access the DB if they really want. Is this the right assesment @ashb ? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
