potiuk commented on issue #24344: URL: https://github.com/apache/airflow/issues/24344#issuecomment-1152614965
Just to explain things you completely misunderstand. You assume we have responsibilities for things that we don't. So let me set your expectations here. It would be great if you read all the information available about what ASF releases and how. You also apparently completely missed our explanation of what the airflow image is and how (if you have higher expectations about the security) YOU can make sure your expectations are met (but it's you who has to spend all the effort). Basically if you have high demands, you have to pay for it. Airfllow (which you get completely free) has very high standards when it comes to security, but your expectations clearly demand higher level and If you want to pay for it (with the time of your security team) - you are not only free to do it but we spent a lot of effort to make it possible. Let me explain then (and please read it VERY carefully before your respond). Ideally, if you demand somethign, It should start with the amount of money your company is willing to pay to get higher security level. There are a number of individuals and companies that I will be able to point you to who have good paid commercial support in case you have noit enough internal security experts. Airflow images are NOT what Airflow or Apache Software Foundation releases "offficially". The only officially released software that the ASF releases are https://downloads.apache.org/airflow/2.3.2/ - this is source of airlflow that you can use having sufficient tools and software to build airflow from the sources. If you are concerned about vulnerabilities in whatever non-airflow-sources part, you are free to download the -src.tgz, follow the instructions and build your software - using whatever third-party OS, compilers etc. you have. This is what is the source of any security vulnerabilities you might raise to the ASF. Any other vuinerabilities you can raise are vulnerabilities in 3rd-party packages and you can raise your vulnerabilities there. The "reference image" is really "convenience package that is also called "compiled" package https://www.apache.org/legal/release-policy.html#compiled-packages and is NOT official release by the ASF. this is a .... "convenience package" that makes it easy to start. BUT this is not something that you have to use - you can build your own image: https://airflow.apache.org/docs/docker-stack/build.html via customization that only uses our source Dockerfile and you can customize the Dockerfile and use other base (CentOS, whatever) than us - we use debian buster. > we will try to figure out how to improve the security. Maybe is another base image, creating a new distroless image and adding a pipelines for vulnerability management. What is the proper channel to bring this proposals? just PRs? If you have ideas how to improve and automate things - absolutely feel free to raise PRs. > we will try to figure out how to improve the security. Maybe is another base image, creating a new distroless image Just a bit of warning - you misunderstand how distroless images work and not understand that they are not good for arlflow. > almost all of them image, not as python dependency Yes. Since this is just convenience image, whatever you see there might come from non-airflow code and this is where you should raise your security issues with. We are basing our images on latest (At the moment of release) security patched debian buster version. Whenever we release new airflow version it uses latest available version of the "official" python debian-based images. https://hub.docker.com/_/python which uses latest official debian as a base. if you see any problems with dependencies we install - raise them to Python team or debian team. Whenever they release their updated versions of images we will automatically use latest images. Our CI pipeline is specifically done in the way to automatically update to latest available Python official image from each line (3.7 - 3.10). We also automatically upgrade dependencies to our And we almost never re-release released images for old versions. Mostly for stability but also because if you want - you can very easily [build your own image](https://airflow.apache.org/docs/docker-stack/build.html#customizing-the-image) following our instructions. If you care about updating to today's Python version of Airlfow 2.1.0 - feel free. It's very much possible. There are even people who establish their CI pipelines and they ise our standalone Dockerfile to build their image every day taking latest versions of the dependencies. While Airflow installation recommends to use constrained python dependencies. it is also possible to roll your own constraints and installation sources (where you can pre-vet and scan your own dependencies in your own PyPI repository): https://airflow.apache.org/docs/docker-stack/build.html#using-custom-installation-sources as well as you can build your airlfow image in highly-seciurity-demanding restricted environment: https://airflow.apache.org/ docs/docker-stack/build.html#build-images-in-security-restricted-environments - there were few people who wanted to build airlfow in air-gaped environment with no connection to external world where they would pre-vet all dependencies in their environment. This is possible. I hopes that gives you a better understanding of what you can, and what you can't expect from the free software delvered by the Apache Software Foundation regarding to your expectations. -- 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]
