La sécurité avec Docker – Chapitre 2 : Le réseau

chained

Chapitre II : Réseau

 

Isoler les réseaux :

 

Les piles de logiciels ou les différents types de réseaux doivent être isolés dans des réseaux logiques séparés.

Créer un réseau par stack logicielle :

docker network create <nomdureseau>
# Attacher les containers au réseau qui va bien
docker network disconnect bridge <leconteneur>
docker network connect <nomdureseau> <leconteneur>

 

Désactiver la communication inter conteneurs (ICC) :

 

Par défaut les containers d’un même réseau peuvent communiquer entre eux même s’ils ne sont pas liés.

Pour ne pas permettre ce comportement, il faut désactiver l’ICC (inter-container communication).

A la création du réseau :

docker network create --opt com.docker.network.bridge.enable_icc=false monreseau

 

J’ai lu à droite à gauche qu’on peut le désactiver pour tout le démon Docker mais cette procédure n’a jamais marché chez moi :

Dans le fichier /etc/default/docker, ajouter cette ligne si elle n’est pas présente :

DOCKER_OPTS="--icc=false"

Choisir les ports qu’on expose :

 

Ne pas exposer n’importe quel port mais uniquement les ports nécessaires à votre application. Si le container n’est pas censé être visible de l’extérieur (une base de donnée, un serveur d’authentification, etc), il ne doit pas avoir de ports exposés.

Typiquement, dans une architecture Nginx / PHP / MariaDB, seul Nginx doit être exposé, les autres sont liés (–link) à Nginx et de ce fait, peuvent communiquer en interne.

 

Cacher les containers derrière un reverse proxy :

 

A l’instar des machines physiques ou VMs. L’idéal est d’utiliser en frontend un reverse proxy qui fasse du WAF et qui redirige les requêtes vers les bons containers.

Traefik peut faire ça (ma préférence à moi), ou Nginx ou Hipache ou encore HAProxy et Apache.

 

 

Sur le même sujet :