GP - Fotolia

Opinion

Introduction aux risques et à la sécurisation de Docker (2e partie)

Le principe de conteneurisation n’est pas nouveau. Il est utilisé pour répondre à une forte demande de productivité et de réduction des coûts d’infrastructure en suivant le courant du « tout est service » : PaaS, IaaS, SaaS, et maintenant Container as a Service.

Sébastien Bernard
par
Publié le: 21 avr. 2017

Docker éveille des curiosités et l’inquiétude persiste autour de sa maturité et de son niveau de sécurité. La solution est encore peu déployée dans des environnements de production. Cependant, quelques règles d’ingénierie, de bon sens et de bonnes pratiques de sécurité permettraient de réduire la surface d’attaque et d’alléger l’angoisse justifiée de ses débuts.

L’explication sur le fonctionnement Docker nous amène déjà à réfléchir à la sécurité des différentes briques de l’application. Une mauvaise configuration du système hôte, du démon docker et aussi des conteneurs eux-mêmes peut conduire à la compromission générale qui se joue principalement autour :

  • Du noyau du système hôte partagé avec le démon docker et les conteneurs. Si un attaquant vient à compromettre le noyau mutualisé entre les conteneurs, l’impact sur le système sera alors général et touchera alors l’ensemble des conteneurs (type Kernel Panic par exemple).

  • De l’élévation de privilège : Un utilisateur root dans un conteneur peut devenir root sur le système hôte et ainsi se voir attribuer les droits d’accès à l’ensemble des conteneurs.

  • De la compromission des images Docker ou contenu obsolète contenant des vulnérabilités. Malgré une vérification des Hash des images du Docker Hub, celles-ci peuvent tout de même contenir du code malveillant.

  • D’une utilisation abusive de l’API qui permet de passer les commandes d’administration au démon Docker. Sans une authentification ou un contrôle d’accès, un utilisateur normal ayant le contrôle de l’API peut facilement devenir root du serveur hôte ou maîtriser l’ensemble des conteneurs.

  • Des dénis de service (DoS) : l’utilisation excessive des ressources du système hôte par un conteneur peut amener à une interruption de service de l’ensemble des autres conteneurs hébergés sur le même système hôte.

Ces risques sont fortement diminués en respectant une liste de bonnes pratiques de configuration et en maintenant le système hôte et les paquets du système et des conteneurs à jour. Des recommandations d’intégration et d’administration sont évidemment nécessaires et se réfèrent plus à un plan de sécurité général en sus et au-delà de la solution Docker elle-même.

Analyse d’une des dernières vulnérabilités et comment s’en prémunir ?

Nous nous penchons ici sur une vulnérabilité récente permettant une élévation de privilège depuis un conteneur vers le système hôte. Elle permet donc à un utilisateur malveillant possédant un accès à l’API Docker sur le serveur hôte de lancer une commande pour créer un nouveau processus (runc exec ou docker exec). Si le conteneur fonctionne en ‘root’ et qu’il est équipé de l’outil ptrace() alors, lors de la création du nouveau processus en root dans le conteneur, ptrace() intercepte l’appel et fournit un moyen d’accès à l’arborescence du système hôte. Docker a corrigé cette vulnérabilité dans la version 1.12.6 en désactivant la présentation du « File Descriptor » du système hôte depuis le conteneur.

  • Type de vulnérabilité : Élévation de privilège

  • Classification : « Reserved » 

  • Risque : Modéré (Impact important/ Exploitation avancée)

  • Version Docker : Inférieure à 1.12.6

  • Chronologie : Découverte du bogue le 29 novembre 2016, vulnérabilité rendue publique le 10 janvier 2017, version de Docker généralisant le correctif 1.12.6 le 10 janvier 2017 (les vulnérabilités sont généralement rendues publiques dès leur correction par l’éditeur). Le temps de correction est tout à fait convenable.

Comment s’en prémunir ?

Ne pas exécuter de conteneur avec des privilèges élevés (en root) et ne pas installer d’outils ayant un accès bas niveau sur le processus tel que ptrace(). Les mécanismes de protection SeLinux/Apparmor et/ou Seccomp viennent complexifier énormément l’aboutissement de cette vulnérabilité

Recommandation

Appliquer le correctif de sécurité mis à disposition par Docker et par l’éditeur du système hôte. Respecter les bonnes pratiques de sécurité permet de se prémunir de cette élévation de privilège.

Synthèse

Cette vulnérabilité est un problème dans le développement de RunC et est aussi apparue dans LXC, l’ancien moteur de conteneur de Docker. Elle n’est rendue possible que si l’administrateur de Docker n’a pas appliqué la dernière version de Docker, la dernière version du noyau de l’hôte et qu’un ensemble de paramètres non conseillés sont appliqués lors du démarrage du conteneur.

Sécurisation de Docker

Il est important de noter également l’évolution impressionnante des versions qui viennent corriger des bogues et des vulnérabilités, mais également apporter d’autres fonctionnalités qui, elles-mêmes conduisent à des vulnérabilités supplémentaires.

Depuis la version 1.7 de juin 2015, plus de 25 versions ont été diffusées, soit plus d’une version par mois. Nouvelle notable de mars 2017 : Docker annonce un plan de mise à jour et de support de type LTS (Long Term Support) sous le doux nom de Docker Enterprise Edition (EE), qui assurera des évolutions de version trimestrielles et une assistance technique maintenue pendant une année complète après sa date de parution. Il devient donc nécessaire de respecter quelques prérequis d’intégration pour y avoir droit ; entre autres le choix du système socle.

Docker a pris conscience de l’enjeu que représente la sécurité et répond à cette demande en intégrant dorénavant une configuration par défaut relativement sécurisée. Il est maintenant question de comment Docker est implémenté dans l’entreprise et sur quelle infrastructure ? 

Plus ou moins complexes à mettre en place et assurant des niveaux de sécurité différents, les axes de sécurisation d’une infrastructure « Dockerisée » sont les suivants :

  • Durcir les serveurs hôtes hébergeant le démon Docker et les conteneurs.

  • Les images doivent être à jour et ne posséder que le strict minimum. Éviter le stockage de secrets au sein d’une image, la présence de ssh ou d’outils d’administration. Moins le conteneur possède d’outils et de paquets, plus la tâche de compromission sera difficile.

  • Construire un réseau cloisonné dont chaque composant Docker se voit attribuer un segment particulier (communication hôte-hôte, conteneurs, administration, servitudes, etc.). Définir des politiques sécurisées de communication et d’administration au sein l’infrastructure.

  • Vérifier les sources de construction des images utilisées par les conteneurs et assurer un suivi de leurs évolutions en appliquant une signature numérique interne.

  • Un scan de vulnérabilité de l’image doit être implémenté avant la validation de celle-ci en tant qu’image de confiance.

  • Limiter les appels système, les ressources d’un conteneur et minimiser l’exécution des conteneurs en mode privilégié. Le UserMapping du User NameSpace est vivement conseillé.

  • Intégrer un mécanisme de contrôle d’accès et de gestion de rôle/profil des utilisateurs/administrateur de la solution (sécuriser l’API par un outil RBAC).

  • Suivre les évolutions de configuration et centraliser les journaux d’événement.

  • Surveiller le niveau de sécurité global régulièrement à l’aide d’audit et de scanneur réseau et applicatif. Cela permet d’identifier les vulnérabilités des serveurs hôtes et des applications hébergées dans des conteneurs et de suivre leur correction.

  • Ne pas exposer directement un conteneur sur Internet, les mécaniques habituelles de protection doivent s’appliquer : Reverse Proxy, Firewall/ WAF, etc.

La conteneurisation facilite le déploiement d’application et dans certains cas, comme pour les environnements de test (si bien isolé dans le réseau), le niveau de sécurité pourra être moins important. C’est pourquoi les recommandations de sécurité sont également ajustables et adaptées au contexte afin de ne pas entraver le travail de chacun, mais pour finalement arriver à un niveau de sécurité élevé dans un contexte de production.

Les conteneurs hébergeant une application sensible devront quant à eux respecter le niveau de sécurité fort et ne pas être mélangés avec des conteneurs moins sensibles. Une séparation physique de ces deux types de conteneurs sur des systèmes hôtes différents réduira la surface d’attaque.

Une image doit être traitée comme un nouveau système d’exploitation en cours de validation et passant par les procédures de vérification de l’entreprise. La validation d’un nouveau master demande un peu d’effort qu’il faudra également adopter pour les images Docker.

La compétition sur le terrain de la conteneurisation est en marche. L’enjeu pour la suite se situera au niveau de l’organisation humaine, de l’orchestration technique de déploiement de conteneur et du suivi des mises à jour des plateformes et des applications conteneurisées. Aujourd’hui encore, industrialiser ces procédures de sécurité s’appuyant sur des outils comme Docker Scanner, Teenable.io, AquaSec, Notary ou Kubernetes reste un vrai défi, et bravo à ceux qui entreprennent ces nouveaux projets. 

Le monde du service et des nouvelles technologies est en plein bouleversement, les mois et années à venir sont prometteurs, à suivre !

Perspectives

Selon le cabinet 451 Research, les conteneurs vont remplir un rôle de plus en plus important dans l'utilisation de la technologie cloud d’ici 2020 avec un taux moyen de croissance annuel prévu de 40 %. Les revenus de la technologie de conteneurs étaient de 495 M$ en 2015 et devraient passer à 2,69 Md$ fin 2020, soit un taux de croissance annuel de 40 % sur la période.

L'utilisation de la technologie Docker en mode cloud est un fort vecteur de croissance. Docker fournissant un nouvel emballage aux applications à utiliser dans le cloud. Cette perspective bien réelle et déjà d’actualité souligne une fois de plus le besoin de sécurité pour ces technologies autant sur l’axe des gestions et remédiations des vulnérabilités que sur l’axe CASB, protection de l’information, traçabilité des usages et des administrateurs, conformité GDPR, etc.

La première partie de cet avis d'expert est disponible ici.

Pour approfondir sur Sécurité du Cloud, SASE