@Jarek - you are right about the use/admin difference, it’s a disambiguation that permeates beyond the airflow UI layer in MWAA - IAM auth is used for determining authN and AuthZ, hence to secure the webserver from un-authorized code, we would have to either a/ treat plugin updates as an elevated permission activity, or b/ separate out the webserver intended requirements/plugins from the ones required for DAGs so that the authZ can be handled separately.
We stayed with the one-DAG-bad ideology to not add complexity to customers and coaching them on "if you add to A it goes here, and if B it goes to webserver". That’s is why we are now between rock and a hard place - not being to open up all installs into webserver OR separate the DAG bag for webserver and other entities. On 6/18/21, 1:36 PM, "Jarek Potiuk" <[email protected]> wrote: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > That would certainly help a bit, but unfortunately it's not just the packages. It's the fact that authentication is tied to Python code that can be patched by anyone with permission to execute code on the web server, which in turn would give them access to packages or any anything else they'd like. But in Airflow 2.0 the code provided by "DAG writers" is not executed any more. This is entirely gone together with Airflow 1.10. This has been handled by DAG serialization, which is the only option available in 2.0. I do not see how the "Users" could add any code if "Admins" control the packages that are installed in the webserver. Now if Admin/User is the only problem then I think this is really misunderstanding coming from the pre-DAG-serialization world of Apache Airflow. J.
