Voir :

• Docker Buildx / BuildKit
• https://docs.docker.com/build/building/best-practices/
• https://docs.openshift.com/container-platform/4.17/openshift_images/create-images.html
• https://docs.oracle.com/en/operating-systems/oracle-linux/podman/podman-SecurityRecommendations.html
• Exemple de Dockerfile pour Dokuwiki
• https://www.docker.com/blog/docker-best-practices-using-tags-and-labels-to-manage-docker-image-sprawl/

Outils / Méthode / Container Image Builders :

• Docker / Dockerfile
• Buildah
• openshift-imagebuilder
• Source-To-Image (S2I)
• Buildpacks / pack
• Kaniko
• S2I
• CNB
• Paketo
• umoci

Voir :

• https://www.sysdig.com/learn-cloud-native/dockerfile-best-practices
• https://collabnix.com/running-docker-containers-as-root/
• https://www.docker.com/blog/understanding-the-docker-user-instruction/
• https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html
• https://blog.stephane-robert.info/docs/conteneurs/outils/hadolint/
• https://medium.com/@SecurityArchitect/hardening-container-images-best-practices-and-examples-for-docker-e941263cab13

Quand cela est possible préférer COPY à ADD. Voir https://docs.docker.com/build/building/best-practices/

Immediately before your ENTRYPOINT or CMD directive, you then add a USER

Ne pas utiliser sudo mais gosu ou su-exec

Voir :

• https://blog.stephane-robert.info/docs/conteneurs/outils/hadolint/

podman run --rm -i docker.io/hadolint/hadolint < Dockerfile

• https://cloud.theodo.com/en/blog/docker-processes-container
• https://ahmet.im/blog/minimal-init-process-for-containers/
• https://github.com/antontkv/docker-and-pid1

https://github.com/browserless/chrome/blob/master/start.sh

start.sh

#!/bin/bash
set -e
 
# When docker restarts, this file is still there,
# so we need to kill it just in case
[ -f /tmp/.X99-lock ] && rm -f /tmp/.X99-lock
 
_kill_procs() {
  kill -TERM $node
  kill -TERM $xvfb
}
 
# Relay quit commands to processes
trap _kill_procs SIGTERM SIGINT
 
Xvfb :99 -screen 0 1024x768x16 -nolisten tcp -nolisten unix &
xvfb=$!
 
export DISPLAY=:99
 
dumb-init -- node ./build/index.js $@ &
node=$!
 
wait $node
wait $xvfb

Dockerfile

CMD ["./start.sh"]

voir https://www.grottedubarbu.fr/buildah-basics/

docker build

buildah bud -t myapp:latest .

L'option bud est en réalité une version courte de l'option build-using-dockerfile

Voir :

• https://blog.saintmalik.me/dumb-init/

Something like dumb-init or tini can be used if you have a process that spawns new processes and you don't have good signal handlers implemented to catch child signals and stop your child if your process should be stopped etc.

If your process doesn't spawn new processes (e.g. Node.js), then this may not be necessary.

I guess that MongoDB, PostgreSQL, … which may run child processes have good signal handlers implemented. Otherwise there would have been zombie processes and someone would have filed an issue to fix this.

Only problem may be the official language images, like node, ruby, golang. They don't have dumb-init/tini in it as you normally don't need them. But it's up to the developer which may implement bad child execution code to either fix the signal handlers or use helper as PID 1.

Source : https://stackoverflow.com/questions/37374310/how-critical-is-dumb-init-for-docker

RUN apk add --no-cache shadow