Si vous êtes sys/netadmin, cette expression vous est peut-être apparue ces dernières années : L’Ia(a)S ou Infrastructure as (a) code. De quoi parle-t-on ? C’est Amazon Web Services qui, le premier a lancé ce terme lié à l’automatisation de l’infra. Dans la logique Devops qui veut que les équipes devs et les équipes ops se rapprochent, il s’agit de mettre en place des infrastructures (systèmes, réseaux, virtualisation, etc.) qui se manipulent comme du code. »
Les slides de ma formation sur Docker sont disponibles sur https://cours.adminrezo.fr. Sur le même sujet : La sécurité avec Docker – Chapitre final : Le test La sécurité avec Docker – Chapitre 3 : Les utilisateurs La sécurité avec Docker – Chapitre 2 : Le réseau »
Chapitre final : Le test ultime Docker Bench Security Vous saurez très vite si vous avez suivi les recommandations de sécurité Docker en utilisant ce petit script qui n’a l’air de rien mais qui en dit long. git clone https://github.com/docker/docker-bench-security.git cd docker-bench-security ./docker-bench-security.sh Verdict ? Plus il y a de rouge et plus c’est méchant ! La checklist du SANS : »
Chapitre III : Utilisateurs Docker ne doit pas être contrôlé par root : Vous devez utiliser un compte standard pour manipuler vos containers et vos images Docker. C’est très simple, il suffit que votre utilisateur appartienne au groupe docker : sudo adduser moi docker docker run ... Les conteneurs ne doivent pas être lancés par root : Un conteneur ne doit pas être lancé en tant qu’utilisateur root sauf s’il y a une utilité particulière. »
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) : »
Après plusieurs années d’expérience, je pourrais résumer Docker en un outil très utile, facile à prendre en main mais vraiment difficile à maîtriser. Le côté « facilité de déploiement » de départ masque les problèmes de sécurité inhérents à la technologie des containers. Or si Docker était encore pointé du doigt pour ses lacunes sécuritaires il y a quelques années, force est de constater que des efforts ont été faits dans ce domaine si on veut bien se donner la peine de mettre les mains dans le cambouis. »
Quand on veut déployer un container docker, rien de plus simple, un docker run suffit à rendre le container disponible. Mais si vous n’avez pas réfléchi avant à l’architecture réseau, vous faites communiquer vos containers dans le réseau par défaut, ce qui n’est pas forcément une bonne idée d’un point de vue sécurité. Les trois type de réseau par défaut Bridge Par défaut, Docker attache les containers au réseau « bridge » qui a été créé à l’installation de Docker. »
Je vous ai parlé l’autre jour des containers LXC sous Proxmox. Il est très simple de lancer un container de base ou de chez TurnkeyLinux. Par contre Proxmox ne permet pas de créer un modèle de container, il va falloir un peu user de la ligne de commande, mais c’est assez simple. Dans cet exemple, je pars de l’image Centos 7 de base (vous devez au préalable l’avoir téléchargé) et j’en fais une image Apache/PHP que je pourrais utiliser de multiples fois. »
Il y a quelque temps maintenant, j’ai pas mal travaillé sur les containers avec Docker. Finalement j’en ai très peu mis en production faute d’outil d’orchestration justement du type Proxmox. Proxmox ne propose pas des containers Docker mais des containers Linux (LXC). Sur le principe c’est la même chose mais les images ne viennent pas du même fournisseur. Chez Docker ça vient du Docker Hub alors que les containers LXC de Proxmox sont puisés chez Turnkey Linux. »
Depuis quelques mois, avec le décollage de Docker, le principe des conteneurs sous Linux en a séduit plus d’un. Docker est le premier à avoir réellement lancé ce marché, il est toujours le grand leader actuel mais il voit de plus en plus de concurrents proposer des solutions alternatives, côté hôte comme côté container : CoreOS est un système hôte très léger d’hypervision et de virtualisation ; Le logiciel de containers associé est Rocket. »