airflow 2.3.2 vulnerabilities in docker images

[vulnk000]

Apache Airflow version

2.3.2 (latest released)

What happened

Vulnerability scanner on apache/airflow images reports several vulnerabilities.

What you think should happen instead

No vulnerabilities should be reported or the reported ones, should be evaluated to determine if they affect or not to this software.

How to reproduce

Scan one of the images.

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v ${PWD}/cache:/root/.cache/ aquasec/trivy:latest apache/airflow:slim-2.3.2-python3.8

You will see python vulnerable packages and base image images.

Operating System

apache/airflow:slim-2.3.2-python3.8 (debian 11.3) But other images report vulnerabilities as well.

Versions of Apache Airflow Providers

No response

Deployment

Other Docker-based deployment

Deployment details

No response

Anything else

If you need I can add the report here in cvs format.

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[boring-cyborg]

Thanks for opening your first issue here! Be sure to follow the issue template!

[potiuk]

We are not going to act on it. As per the Apache Software Foundetion Security policy - bulk security vulnerability reports are not going to be analyzed nor acted upon - mostly because they provide many false positives, so it is counter-productive to spend time on those reports.

@vulnk000 - if yoy wish to report real security vulnerabilities, you should follow the security policy. If you will find (among the security problems that your tool reports) vulnerabilities that are exploitable and you have reproduction scenario, please follow the policy: https://github.com/apache/airflow/security/policy and report them (including those reproduction scenarios) to security@apache.org (one report per vulnerability).

[vulnk000]

Hello,

I completely understand your answer and the motivations behind. But please, if you are not going to treat vuln reports, add it to your security policy please, as this specific case is not mentioned and for sure it will be common.

In the other hand, I don't agree with your statement. You are releasing software with vulnerabilities that may be exploited in several ways or not. But we don't know because (correct me if I'm wrong) you are not looking them. If reports have +200 vulnerabiliteis, maybe there is something wrong behind that may explain these 200 vulns (almost all of them image, not as python dependency).

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?

[potiuk]

In the other hand, I don't agree with your statement. You are releasing software with vulnerabilities that may be exploited in several ways or not. But we don't know because (correct me if I'm wrong) you are not looking them. If reports have +200 vulnerabiliteis, maybe there is something wrong behind that may explain these 200 vulns (almost all of them image, not as python dependency).

I completely understand your answer and the motivations behind. But please, if you are not going to treat vuln reports, add it to your security policy please, as this specific case is not mentioned and for sure it will be common.

You probably have not read it initially and even after I pointed you to https://github.com/apache/airflow/security/policy . This is all described there and in the ASF policy, you just did not spend your time on reading it. Please stop writing and start reading. Also this is the ASF policy. You can raise this point to security@apache.org if you think it is not described well enough.

[potiuk]

Just to explain things you completely misunderstand. You assume we have responsibilities for things that we don't. So let me set expectations here. It would be great if you read all the information available about what ASF releases and how before continuing the thread.

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 (with time of people who will follow the helpful guidelines we prepared). 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 reference Airflow image. Airflow "reference image" requires package managers because most people will customize or extend it. We cannot doliver "distroless" image - simply because it's never "done". Distroless images are good for "applications" and "finished products" - something what you treat as "binary" to run. But Airflow is a platform, not application and by definition it needs to be extended by installing more software - more python packages, more os packages. So there must be some package managers in the Airlfow "reference" image that we produce - something that will allow our users to install more software, otherwise it will be useless.

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 during our CI so what you get when we release an image is the set of "latest working" dependencies - that were available at the moment of release.

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 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 if you want - you just need finally start paying (either by the time of your team or hired experts) to get "commercial" level of support (analysing and responding to security reports in bulk is precisely something that costs a lot of money to filter out false-positives)..

I hope 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.

[potiuk]

maybe there is something wrong behind that may explain these 200 vulns (almost all of them image, not as python dependency).

One more thing. Please. By all means do. Analyse those. And let us know when you find real vulnerability find reproduction scenario and describe it in the way that we can assess severity (one mail to security@ per issue). This is one of the best ways you and your company can pay back for the absolutely free software you get.