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?
