The Dockerfiles created by the extension are insecure

[itamarst]

1. They shouldn't run as root (https://pythonspeed.com/articles/root-capabilities-docker-security/).

2. They should update system packages to get the latest security updates (RUN apt-get update && apt-get -y upgrade).

[BigMorty]

Thanks @itamarst for your feedback, we will look into these concerns.

[BigMorty]

Thanks for your helpful feedback! Our team discussed your suggestions and I wanted to let you know that our next release of the VS Code Docker extension will include an update to scaffold a Dockerfile that will run the container as a non-root user. In the future, we would ask you to first share security concerns with us privately to prevent exploitations.

In reference to updating system packages in the Dockerfile we scaffold, we do not plan to make that change. The reason is because we want to have reproducible builds. If a project is left untouched for some amount of time, a build that worked with one set of dependencies may become incompatible when every dependency is updated.

Thanks for your support and use of our product,
Mike

[itamarst]

Thanks for fixing the root issue.

Re system packages—while reproducibility is a useful goal, not doing security updates doesn't actually improve reproducibility in a particularly meaningful way.

1. The base image isn't going to be identical. Partially this is due to choices you've made: you're using python:3.8 by default, which means it's going to be 3.8.2, then 3.8.3, etc.. Plus, you're not specifying an operating system, so at some point when next Debian release comes out and user rebuilds from scratch, their base OS will switch from Debian 10 to Debian 11, which is very much not reproducible. So as a starting point, if you want at least some vague level of reproducibility use python:3.8-buster as base image.
2. The python:3.8 image (or any other Python base image) is going to be rebuilt every few weeks, so system packages on the base image are going to change. Not much you can do about it, unless you want to switch to a more stable base image (the Bitnami base images have permanent tags guaranteed to be completely stable).
3. That being said, worries about lack of reproducibility from stable Debian are overblown. Assuming you switch to python:3.8-buster, in general Debian will strive for backwards compatibility in system packages; yes, occasionally backwards compatibility will slip through, but usually not.
4. The real problem with lack of reproducibility in practice tends to be Python packages, as listed in requirements.txt. If you want to actually have reproducibility you need to transitively pin those using pip-tools (or Poetry, or Pipenv though that project appears dead).

So basically you're not doing security updates in a misguided attempt to be reproducible, while ignoring the two places that actually make for non-reproducible builds:

• You should switch to python:3.8-buster as base image, so the next Debian release doesn't break all your users images when they rebuild.
• You should ensure you have a transitively pinned requirements.txt. https://pythonspeed.com/articles/pipenv-docker/ covers how to do this.

[BigMorty]

Thank you again for the feedback!

We have opened issue #1877 to change the base Python image to use 3.8-slim-buster.

Our extension will generate requirements.txt file if it is not already present. In that file we refer to specific version of the application direct dependencies (Flask, Django and gunicorn), and provide a comment that tells the user how to pin all dependencies using pip freeze. Package versioning policy is something that each user and organization ultimately have to decide for themselves. We believe what the tool is doing today is a good starting point.

We appreciate your help with improving VS Code Docker extension.