Docker image build

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

Bonnes pratiques

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

Vérif Dockerfile Conrainerfile avec Hadolint

Voir :

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

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

Init process

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

Exemple de Dockerfile et script

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"]

Buildha

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

pid1

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

Autres

RUN apk add --no-cache shadow