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 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. 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?
