I agree that this thread is probably not good for categorization of the offering but I also concur with Ash to get a better understanding of the risks involved.
I think I "feel" where it comes from and intuitively see that you might want to add additional or extra layers of precautions (and likely follow pressures from the internal security teams) but also Ash's point is quite important. We should get to the bottom of it, and if there are some real threats that we are not aware of, I think sharing details on [email protected] is the right thing to do. Maybe we will find that other users of Airflow are also at risk and we might want to protect them (and also all managed services but also individual installations) in the future by introducing some changes in this model. BTW. Subash - you do not need to have a subscription to write to [email protected]. Just send an -email with the details and we will get it and we will be able to keep you in discussion when it follows. Also information for your security team https://www.apache.org/dev/pmc.html#mailing-list-private . One of the main purposes of the private@ mailing list is pre-disclosing security problems related to the project. And we are all obliged as PMCs (and all ASF members who read the list as well) to not disclose what is discussed there. J, On Fri, Jun 18, 2021 at 4:04 PM Ash Berlin-Taylor <[email protected]> wrote: > > No one as yet explained what the security concerns actually are? Is there > some concrete thing that is a worry, is it merely a concern that more things > installed = marginally more risky? > > The blast radius is limited to a single Airflow deployment, and access is I > assume sufficiently gated behind IAM perms anyway? > > By not letting users install extra modules in to the webserver image you are > also removing their ability to use third party providers, such as these > > https://github.com/great-expectations/airflow-provider-great-expectations > https://github.com/fivetran/airflow-provider-fivetran > https://github.com/anyscale/airflow-provider-ray > > -- and there are only going to be more of these over time. > > Not to mention this blocks UI plugins entirely. > > I don't quite understand why MWAA concerns itself with exactly what is being > installed in the webserver image on top of Airflow -- the Amazon Shared > Responsibility model would I think already cover the "AWS takes care of the > base, 'you' take care of what is running" (but I confess I haven't re-read it > in a number of years) > > -ash > > On Fri, Jun 18 2021 at 07:06:53 +0000, "Canapathy, Subash" > <[email protected]> wrote: > > Irrespective of personal categorization of the managed offerings > Airflow-ness, there are obligations to adhere to a security bar and securing > against any attack vectors a UI feature can introduce – and this will be true > for any cloud service provider. I want to clarify that we were not suggesting > to change any assumptions in current way of packaging providers but merely > citing that we cannot use equivalence to earlier mono repo and add all 60+ of > them on base image. > > > > Going back to the original discussion, we are in the process of > pre-installing providers with Apache 2 license right away and others will be > added (with approved exception) based on user demand. > > > > From: Ash Berlin-Taylor <[email protected]> > Reply-To: "[email protected]" <[email protected]> > Date: Wednesday, June 16, 2021 at 1:11 AM > To: "[email protected]" <[email protected]> > Subject: RE: [EXTERNAL] [DISCUSS] Managing provider Connections via UI in > managed Airflow services > > > > On Tue, Jun 15 2021 at 18:21:56 +0000, "Canapathy, Subash" > <[email protected]> wrote: > > Regarding security constraints on why we disallow plugins and requirements on > the webserver, I will have to discuss this in person on PMC but on a high > level this comes down to remote code execution prevention on managed > instances, opening possibilities of exploiting vulnerabilities on the > flask-app-builder and the underlying python runtime. > > > > I'm sorry, I don't agree with this summary. > > > > Airflow's job is to run user submitted code, and to allow the UI to be > pluggable. > > > > Are you providing Airflow, or an Airflow like service? -- +48 660 796 129
