unit
unit copied to clipboard
nginx
Docker: for python based images, use the -slim version
After a conversation with @MichaelMcAleer and our docker initiatives, he suggested we use the -slim variant python images as base when creating the unit-python dockerfiles.
Main reason is the slim image has a lot fewer packages and therefore a lot smaller vulnerability surface and count.
The functionality would not change.
He also suggested we take a look at how ingress controller generates images: https://github.com/nginxinc/kubernetes-ingress/blob/main/.github/workflows/build-base-images.yml
python:*-slim Doesn't contain curl(1) which can limit the ability to manage/configure Unit in a container. Until we have a zero-dependency, fully-featured CLI tool…
See https://github.com/nginx/unit/issues/725 and https://github.com/nginx/unit/issues/622 and https://github.com/nginx/unit/issues/519 for some related details. The functionality does indeed change.
@thresheek I had a look through https://github.com/nginx/unit/issues/725 and https://github.com/nginx/unit/issues/622 and https://github.com/nginx/unit/issues/519.
I want to reiterate what @javorszky said in the issue description but with more context. I asked if using the -slim variant of the python image was a possibility due to the amount of packages in the main image (720 vs 303) which significantly increases our attack surface. The -slim variant comes with 91 fewer detected vulnerabilities (-1 critical, -2 high, -3 medium, -86 low). I do not have a concern with the final size of the image, only the security posture and dependency requirements.
The impact on functionality is project specific to what I was discussing with @javorszky , its not a general comment on what is and isn't included in the image, as @lcrilly pointed out -slim doesn't come with curl(1). I will admit that this is unclear from the description.
I think it is worth discussing from a security perspective, weighing up the pros and cons, and determining if there is a path forward for a slim variant. There is no hard timeline on this, happy to wait if a solution requires something like unitctl.
This is not an urgent ask, so can definitely wait until unitctl :)
@javorszky may I ask what exactly we are waiting for? Unitctl is present and functional. Most remaining items in the overarching CLI ticket are nonbreaking improvements to the unitctl code or feature adds that make existing functionality easier.
Is there some feature we are waiting on? The release mechanism is in place and ready. Next Unit release will include a release of unitctl.
@javorszky may I ask what exactly we are waiting for?
@lcrilly had this ask, I assume we're waiting for that
Until we have a zero-dependency, fully-featured CLI tool…
Let's switch to the -slim variant and apt-get install curl in our Dockerfile. Then we're fully unblocked, and curl is nice to have regardless of unitc vs unitctl
My problem with the slim-based image is that we will impose additional hurdles on the consumers due to the fact they might need to install additional Debian packages to be able to do a simple pip install -r requirements.txt that used to work in the non-slim variant. e.g. it lacks gcc which means that if there is not an already compiled distribution as fetchable by pip, it will fail on the build step.
If you feel it's an OK breakage to implement given the idea we want to have as less friction as possible in using Unit, then we can move and document the new behaviour.
I think adding the -slim based python images alongside of, rather than instead of the full python base image should serve everyone. Then we can figure out the usage numbers and carry on from there.
If we also have a list of packages that the -slim image is missing that are usually required, like curl, gcc, we can add them back in, and it would still result in an image with fewer security issues.
I think adding the -slim based python images alongside of, rather than instead of the full python base image should serve everyone.
But then we're also publishing Docker images with two different experiences. Should pip install work or not work? How will we document the variance in behaviour?
Should you be able to switch between slim and non-slim? Or is it OK for that to be a breaking change?
I don't have a strong opinion about this either way, but I want us to be mindful of the total impact.
All of these are great questions to answer on our documentation page. It's the same issue as the python official docker images have: they also provide two (four) different experiences, and they have documentation on what each image variant does or does not have and which one folks should be using: https://hub.docker.com/_/python, scroll down to the "Image Variants" heading (there's no css ID on it, I can't anchor link to it directly).
These are easily solvable questions that most docker images that are vastly more popular to unit have already solved in a fairly standard way.
Should pip install work or not work? How will we document the variance in behaviour?
In my case pip worked fine with the -slim variant, but this does not mean it will work in every scenario like @thresheek mentioned.
We can add curl, gcc and other build-essentials as required, being additive I believe is a better approach than including the world for convenience. It also aligns better with security principles around dependency accquisition and what is included in a final container image.
A -slim variant can be supplied along side the 'full fat' version so to speak, we can offer both and outline the differences so users can make an informed decision on what works for them. They might try -slim then realise their use-case involves quite a bit of set-up so they can make the trade-offs and go for the alternative with everything included.
If we choose to extend the slim version of a python image, it will be somewhere between the slim and non-slim variants. The full python image is based on the following Dockerfile: https://github.com/docker-library/buildpack-deps/blob/master/debian/bookworm/Dockerfile (it also installs git, mercurial, curl and openssh-client in the 'scm' variant). I'm not sure if it's a good idea to deviate and create a slim-plus or almost-fat image...
I agree with @javorszky that we can try shipping images based on both slim and full version. Seems like a best compromise to me.
Those images will hopefully be available after we issue a new Unit release & the image get propagated to Docker Hub.