![]() Project name: docker-image|python-flask-distroless Scanning it with docker scan gave me the following: Package manager: deb So, I ended up with the following Dockerfile allowing me to install Flask in a distroless Python image: # Build imageĬOPY -from=build-env /usr/local/bin/flask /usr/local/bin/flaskĬOPY -from=build-env /usr/local/lib/python3.7/site-packages /usr/local/lib/python3.7/site-packagesĮNV PYTHONPATH=/usr/local/lib/python3.7/site-packages But it didn't work out well, because the base distroless image makes some opinionated choices on the filesystem layout:Įxpectedly, a Linux distr is still there, but it's thinner than even debian-slim At first, I was trying to utilize a virtual environment in the build image, then copy it to the runtime image, and hack the PATH variable. Python distroless containers require multi-stage building process because the gcr.io/distroless/python3 image has neither pip nor even easy_install. However, installing Flask (or any other dependencies) turned out to be much tricker than I expected. Most of the examples out there show how to use some trivial scripts. ![]() It took me a while to come up with the working distroless Python image. Although it'd be hard to achieve in the case of Python since its standard library relies on some higher-level OS capabilities. The project description states it's "Language focused docker images, minus the operating system". bit above, lots, if not all, of items in the report have it).Īpparently, python:3.9 image is based on the full-fledged Debian 10 distributive:ĥ.6 MB - Alpine rocks! Scanning distroless Python imageĪnother potential solution for the problem of bloated containers that looks promising is so-called "distroless" Docker images by Google. Taking a closer look at the scan report gave me a clue that the majority of the found vulnerabilities might have something to do with Debian (see the Info. Tested 431 dependencies for known vulnerabilities, found 358 vulnerabilities.įor more free scans that keep your images secure, sign up to Snyk at ģ58 vulnerabilities were found in total: among them, 54 were high severity and 48 medium severity. ![]() ✗ High severity vulnerability found in bluez/libbluetooth3 ✗ High severity vulnerability found in djvulibre/libdjvulibre21 ✗ High severity vulnerability found in gcc-8 Introduced through: > Low severity vulnerability found in tiff/libtiff5 ✗ Low severity vulnerability found in unbound/libunbound8 To my utter surprise, the output was huge! Here is just an excerpt:īuilt with ConvertKit Testing python-flask. And it just so happened that it was a fairly basic thing: # latest stable at the time So, I decided, mostly for the sake of fun, to scan one of my images. Apparently, it's some sort of a vulnerability scanner. The docker scan command uses a third-party tool, called Snyk Container. I've been ignoring its existence for a while, so evidently, it was time to finally try it out. I was hacking containers recently and noticed, that Docker started featuring the docker scan command in the docker build output. not every dependency library provides builds for this platform.because reportedly musl libc is slower than glibc.despite very good scan results, Alpine images not always work great.and that's why the most typical solution seems to be simply ignoring the problem □.but of course, it complicates things a lot which leads to a fair suggestion to control the source repositories.and potential regressions due to backports changing the default behavior of dependencies.but others argue back that it'll result in non-reproducible builds I tried and it gave a very minor reduction in the case of full-fledged Debian 10 distr.some people suggest adding RUN apt-get update & apt-get -y upgrade in the beginning of every Dockerfile.but not every developer is aware of that yet with the raise of containers, the burden of patching OS de facto moved from admin & ops people to developers.official base images are never (or very rarely) updated in repos (e.g.some can be simply unrelated because they are specific to some esoteric architectures.some of the reported findings can already be patched in the upstream and backported.vulnerability scanners tend to have lots of false positives.UPD: This post unexpectedly made it to the Hacker News front page and sparked a fruitful discussion there.
0 Comments
Leave a Reply. |