Je plussoie le message de xataz, et je rajouterais pour le socket, dans le cas où tu as besoin de l'utiliser, d'avoir recours à un proxy granulaire comme celui-là : https://github.com/Tecnativa/docker-socket-proxy

Pour gérer l'isolation réseau des conteneurs utiliser des networks bridge que tu définis toi-même (plutôt que d'utiliser le bridge par défaut et d'utiliser des links, dépréciés d'ailleurs). Utilise le flag --internal si tu veux isoler un réseau de l'Internet par exemple (doit y avoir quelques précisions en plus).

Pour iptables, depuis les versions récentes de Docker, utilise la chaîne DOCKER-USER, puis dedans ajoute une chaîne de filtre qui accepte le traffic prévu vers l'extérieur, puis rejette le reste.

Enfin pour les runtimes je trouve que c'est un peu compliqué encore de conseiller ça, même si le niveau d'isolation est step up encore davantage. Je joue d'ailleurs avec actuellement pour voir comment bien le gérer (a priori c'est surtout niveau réseau que ça se corse car la résolution DNS par Docker ne fonctionne pas sans la stack réseau de l'hôte - mais tu peux y parer en définissant des adresses statiques).

Je ne sais pas si j'ai bien compris mais le user-namespace et l'arg "user: PID:GID" semblent correspondre à la même chose ? Sauf qu'avec le user-namespace tu ne déclares pas à chaque fois un user ? Et ce serait juste l'utilisateur qui exécute l'image ?

Alors y a plusieurs différences.

• Le paramètre --user définit le user (UID/GID) par défaut du conteneur. Par défaut, sauf si USER est déclaré dans un Dockerfile, ça sera root.
• Le user namespace est une feature du kernel qui permet de mapper différents user pour faire en sorte, par exemple, que root dans le conteneur =/= root sur l'hôte (ce qui empêche des catastrophes en cas de compromission d'un conteneur).
• Enfin, certaines images proposent des variables d'environnement (ENV dans le Dockerfile) pour effectivement configurer un utilisateur. Ca ne garantit pas qu'il n'y a pas de root process dans le conteneur, par contre, mais c'est flexible et ça utilise la stratégie du "degrading privileges" (qui a ses défauts aussi).

En gros il faut utiliser un peu de tout ça selon ton besoin, tes images. Idéalement le namespace pour pas qu'un root escape soit dangereux pour la sécurité de l'hôte (d'ailleurs considère que n'importe quel user non-root qui a accès à Docker sans namespace sur l'hôte a tous les pouvoirs....), le paramètre user pour correspondre à tes besoins, et certaines images avec les variables qui "font tout".

Ce ne sont pas vraiment les mêmes choses mais ce sont des moyens mis en oeuvre pour plus ou moins le même but. Et c'est assez compliqué, j'en conviens...

C'est une excellente question quant à l'ICC et l'usage de --link.
Le link est effectivement déprécié : https://docs.docker.com/network/links/

Du coup pour ICC, je ne sais pas trop si c'est encore d'actualité, j'attendrais le retour de quelqu'un de plus expérimenté comme xataz. Je ferai des recherches approfondies dessus, mais il me semble que l'ICC aujourd'hui ne s'applique qu'au bridge par défaut.

L'idée c'est effectivement de gérer tes propres réseaux désormais. Par exemple imaginons tu un conteneur Postgres, il est inutile qu'il soit dans le réseau "frontend", et aussi inutile qu'il soit connecté à l'extérieur (d'où --internal). Tu pourras créer un réseau isolé dédié à l'app en question (app <-> db <-> redis par exemple).

Effectivement pour Traefik le plus commun est de créer un gros réseau dédié, c'est le plus simple. Par contre, toutes les apps de ce réseau peuvent communiquer entre "elles" donc il faut effectivement faire attention si par exemple la sécurité d'une app repose sur le proxy.

Alors il me semble (à vérifier) que Traefik doit simplement pouvoir router vers ces différents conteneurs, donc tu peux voir le sujet à l'envers et faire des réseaux uniques pour chaque lien Traefik <-> conteneur. Mais ça demande un peu plus de configuration, par contre c'est nécessaire pour vraiment bien isoler entre des conteneurs qui n'ont pas besoin de communiquer entre eux (et c'est la bonne pratique).

Pour iptables, la chaine DOCKER-USER est à configurer soi-même ou par défaut elle laisse passer le trafic de/vers l'extérieur ?

Elle est là par défaut, et oui elle laisse passer le traffic. Après pour bloquer spécifiquement l'accès d'un réseau Docker à l'extérieur, je n'ai pas utilisé iptables personnellement.

Tu utilises un daemon.json pour configurer le daemon Docker ? Si oui, tu pourrais le partager pour avoir une idée ?

Oui j'utilise daemon.json, le mien est très simple (enfin c'est relatif) et sur mon serveur perso je n'utilise pas encore le rootless. J'ai juste mis btrfs, le live restore activé, les runtimes alternatifs (gvisor, kata), etc. Rien de spécial !

{
    "data-root": "/docker",
    "debug": false,
    "live-restore": true,
    "userland-proxy": false,
    "iptables": true,
    "icc": false,
    "runtimes": {
        "runsc": {
            "path": "/usr/bin/runsc"
        },
        "kata": {
            "path": "/snap/bin/kata-containers.runtime"
        }
    },
    "storage-driver": "btrfs"
}

(Pourquoi je n'utilise pas les user namespaces : pas compatibles avec kata et gvisor, et c'est redondant avec eux. gvisor par exemple fonctionne avec son namespace séparé de l'hôte. Sinon, je conseille de l'utiliser, c'est une isolation bonne à prendre avec runc.)

Je vais revoir ce point, passer le backend en internal (le paramètre est aussi valable pour un bridge ? Je n'ai trouvé des utilisations qu'avec overlay jusqu'à présent mais je n'ai qu'un hôte Docker).

Visiblement oui. Dans mon docker-compose quand je spécifie un réseau qui doit être isolé de l'extérieur, j'utilise internal: true.

Les réseaux configurés au sein d'un même docker-compose n'ont pas de visibilité entre eux ?

Tu peux avoir plein de réseaux dans un même compose, ça ne pose pas de soucis. La visibilité c'est dès lors que 2 ou plus de conteneurs sont dans un même réseau. (Ou si tu utilises l'option host, mais déconseillé sauf cas particulier.)

Pour iptables, je suis loin d'être un expert Linux mais tu utilises quoi du coup ?

J'ai un iptables.conf basique comme ça :

*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:FILTERS - [0:0]
:DOCKER-USER - [0:0]

-F INPUT
-F DOCKER-USER
-F FILTERS

-A INPUT -i lo -j ACCEPT
-A INPUT -j FILTERS

-A DOCKER-USER -i eno1 -j FILTERS

# Allow existing connections
-A FILTERS -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow ping
-A FILTERS -p icmp --icmp-type echo-request -j ACCEPT

# Allow HTTP
-A FILTERS -p tcp --dport 8080 -m conntrack --ctstate NEW --ctorigdstport 80 -j ACCEPT
-A FILTERS -p tcp --dport 4430 -m conntrack --ctstate NEW --ctorigdstport 443 -j ACCEPT

# Allow containers to interact with full addresses
-A FILTERS -m state --state NEW -p tcp --dport 80 -j ACCEPT
-A FILTERS -m state --state NEW -p tcp --dport 443 -j ACCEPT

# Allow SSH
-A FILTERS -m state --state NEW -p tcp --dport 22 -j ACCEPT

# Reject everything else
-A FILTERS -j REJECT --reject-with icmp-host-prohibited

COMMIT

C'est à titre d'exemple, j'ai viré des besoins perso, mais tu vois l'idée. (Et mes règles HTTP/HTTPS sont bizarres car mon conteneur Traefik est non-root.)

Il faut que je teste si la désactivation de l'ICC dans le daemon.json avant la création de nouveaux réseaux applique automatiquement la désactivation de l'ICC

De ce que j'avais compris l'ICC en tant qu'option n'a plus de sens dès lors que tu gères tes user-defined bridges. C'était surtout valable à l'époque quand il n'y avait qu'un seul bridge, etc.

J'attendrais xataz pour t'en dire plus dessus.

Comme dit, ce paramètre ne s'applique a priori qu'au bridge par défaut. C'était une option plus ou moins indispensable avant que Docker ne se développe, car par défaut, tous les conteneurs étaient sur le même réseau. Pas terrible niveau isolation, donc c'était mieux de tout restreindre et d'utiliser des --link pour décider qui communique avec qui.

Docker a évolué depuis et comme dit, tu peux créer tes propres réseaux bridge (user-defined bridge). C'est la façon "moderne" de faire communiquer des conteneurs entre eux. C'est aussi simple que ça :

docker network create mon_reseau
docker run -d --network mon_reseau --name conteneur_1 image_1
docker run -d --network mon_reseau --name conteneur_2 image_2

Et l'équivalent docker-compose est possible aussi.
Et pouf les 2 conteneurs vont pouvoir communiquer ensemble. Les user-defined bridge ont la particularité de permettre une résolution DNS via Docker (contrairement au bridge par défaut qui utilisait /etc/hosts). Par exemple dans conteneur_1, tu peux tout à fait ping/curl conteneur_2 par exemple. A noter qu'avec des runtimes isolés, cette résolution DNS ne fonctionnera pas, donc il faut passer par des IP statiques, c'est pour ça je ne conseille pas pour l'instant de changer de runtime.

Par exemple pour Traefik, tu peux créer un réseau app_frontend et ajouter Traefik et ton app à ce réseau, que tu précises à Traefik via le label sur l'app. Et imaginons que tu veuilles un réseau interne à ton app pour qu'elle communique avec un conteneur SQL, tu ajouteras les deux à un réseau commun (avec le flag --internal pour l'isoler de l'extérieur).

En résumé, te casse pas la tête avec l'ICC, les --link et tout, fais des réseaux par groupe de conteneurs qui doivent communiquer entre eux !

NicCo Je pense que c'est jouable, c'est pas dur à installer, ça demande en soit pas de configuration par défaut. Le but de gVisor c'est vraiment d'apporter des conteneurs sandboxés à tout le monde sans les défauts des VM.

Alors le problème, c'est que peut-être tes applications ne tourneront pas bien avec gVisor. Faut tester au cas par cas, si tout va bien pour toi, alors franchement je ne vois pas le défaut, t'as une sécurité digne de production.

Du coup non, pas besoin de cette option comme expliqué ici.