Open somera opened 2 years ago
For the author, the tool this person is using is called trivy.
Basically, you set up CI/CD and the occasional (e.g. daily/weekly) checks on your images to literally just to trivy scan $image
and see if there's any vulnerabilities within your dependencies.
Combined with github's dependabot, which checks individual layers of Dockerfile to see if there's anything to be updated, once you "pin" dependencies in dockerfile, you'll be able to reproducibly create container images and have them up to date with the latest patches.
At least that's the theory (I understand that this is a pain in the ass to setup and in fact, I don't even do it for my own application containers lul).
How serious is this?
While Docker processes are supposed to be isolated, let's not kid ourselves: that layer of isolation has a LOT of goddamn holes in it. But you can't really "escape" process isolation (no matter how bad Docker is) when the process in dockerfile does NOT run as root user (because when you run as root user in docker container, and you run Docker daemon as root - which is the default, you can essentially think of your container process as running as root due to the said "holes" providing larger blast radius).
But, uh, you seem to be using the root user for your dockerfile: https://github.com/pawelmalak/flame/blob/master/.docker/Dockerfile
For reference, this is how you would do it "properly", running the process as a non-root user (and reaping any zombies, but that's a topic for another day): https://github.com/JaneJeon/blink/blob/master/Dockerfile#L42
So for the shorter term solution (to limit the "blast radius" to just inside your container), you should change your docker process to run as a non-root user (for all node-based images, there's the node
user). That honestly should be enough to close this issue - after all, Docker's whole point is process isolation.
For the longer term solution, yeah, you should set up automated process with trivy & dependabot to ensure your image is secure and up to date, but if that scares you, it's not a big deal (again, because the attack surface area would be limited by the fact that whatever "hijacks" your container, it would be contained to that container).
Phew
Hope it makes sense @pawelmalak
Is specifying user on the building stage also required?
Not necessarily, but I do it anyway for consistency. Plus there are... "issues" stemming from who owns what if you create assets as root, but this is out of my depth of expertise so Google will serve you better than I can.
It seems that I have to run builder as a root user, otherwise React build fails. Final stage with node user works fine.
Please update.