Réseau Docker pour conteneurs

Réseau Docker pour conteneurs

Authenticité des images

Les images Docker peuvent être accédées et téléchargées depuis Docker Hub ou d’autres dépôts en ligne. Il est donc nécessaire de vérifier la provenance de ces images (de préférence avec des preuves de sécurité à l’appui) et le développeur de l’image doit être considéré comme fiable.
Il est recommandé d’activer DOCKER_CONTENT_TRUST (export DOCKER_CONTENT_TRUST=1) pour autoriser uniquement le téléchargement d’images de confiance (« signées »).
Il est possible d’installer un serveur de registre (dépôt) Docker interne à l’entreprise, pour que les images restent « sous notre contrôle », ce qui est un objectif secondaire du cahier des charges, qui ne sera pas implémenté par manque de temps restant.

Container breakout

Ce terme container breakout représente le fait qu’un conteneur a réussi à passer outre les vérifications d’isolation et peut accéder à des informations sur la machine hôte interne ou acquérir des accès privilégiés.
Comme indiqué dans les Best practices Docker, il faut éviter dans la mesure du possible de démarrer des conteneurs avec des accès « super-utilisateur » (root par exemple).
Par ailleurs, comme indiqué dans la documentation Docker, les conteneurs ont la possibilité d’être isolés à travers des user namespaces.

Surcharge des ressources (déni de service)

Le principe d’une attaque de type « déni de service » (Denial-of-Service en anglais ou DoS) est de surcharger l’utilisation des ressources telles que la mémoire, les processeurs et les interfaces réseau pour rendre un service inutilisable ou pour provoquer un manque de ces ressources pour d’autres processus (et conteneurs dans notre cas). Tel qu’indiqué précédemment, nous établissons des limites de mémoire et de processeur au niveau du service Docker.

Man-in-the-Middle

Le terme Man-in-the-Middle (« Homme au milieu » en français) fait référence à l’intrusion une personne malintentionnée (hacker) au sein d’un réseau entre deux partis (par exemple entre un service Web et un autre serveur) pour visualiser, modifier, supprimer ou voler des informations transmises lors d’une communication.
Une solution à ce problème est d’isoler les réseaux, tel que nous le faisons plus loin dans ce document, afin d’éviter une intrusion externe dans le conteneur. De plus, nous pouvons utiliser des réseaux privés virtuels (Virtual Private Network ou VPN en anglais), mais nous ne nous attardons pas sur cette option à cause de manque de temps et ce n’est pas un objectif du cahier des charges.
Pour finir, il faut utiliser le protocole Web sécurisé (HTTPs) au lieu de HTTP, d’autant plus que dans notre cas, des résultats de recherche transitent entre un serveur et l’interface Web cliente notamment.

ARP Spoofing

Les réseaux utilisent ce qu’on appelle des tables ARP (Address Resolution Protocol), ce qui permet de lier l’adresse physique unique (MAC) d’une machine à une adresse IP. Cette attaque permet donc à un hacker de lier son adresse MAC à une adresse IP du réseau interne (donc légitime) afin de surveiller, sniffer le trafic réseau et les informations sensibles qui y transitent, voire injecter des virus ou maliciels (malwares en anglais). Docker offre la possibilité d’utiliser ebtables pour filtrer le trafic et bloquer ces usurpations.

Crédenciales et Docker secrets

Tous les mots de passes et les clés de sécurité doivent être protégés de façon adéquate.
Par ailleurs, il est recommandé de ne pas utiliser des variables d’environnement pour accéder à des Docker secrets et de régler les conteneurs en lecture seule.

Modification de données

Le code des chercheurs accède à des données sensibles. Il est donc absolument primordial que les données et leurs emplacements ne puissent pas être modifiés ou supprimés.
Lorsque nous ajoutons un point de montage avec bind mount dans un conteneur, il faut que celui-ci soit en lecture seule (readonly).

Accès à des volumes de données non-autorisés

Il est important que le code d’un chercheur accède uniquement aux données correspondantes aux besoins de celui-ci, pour éviter des erreurs d’analyse ou un accès non autorisé.
Le service Web doit donc créer les points de montage vers les volumes corrects dans le conteneur Docker.

Fuite de données vers l’extérieur

Les informations sensibles sont une mine d’or pour les hackers. Il est donc nécessaire, en plus des éléments cités précédemment, d’isoler le réseau d’un conteneur pour éviter une communication de ces données vers l’extérieur, ce qui peut avoir de graves conséquences au niveau des données du patient, pour la réputation de l’institution impactée et par rapport à la loi.

Accès non-autorisé aux résultats d’analyse

Comme expliqué dans ce rapport, les chercheurs du milieu hospitalier demandent l’exécution d’un conteneur avec l’image Docker souhaitée et les résultats sont affichés sur l’interface Web. Il est donc recommandé de mettre en place un mécanisme d’authentification sur cette interface (lien avec la session de l’ordinateur professionnel, ajout d’une page de login) pour restreindre l’accès à ces résultats uniquement aux chercheurs concernés par la recherche.

Solutions d’analyse / protection

La société Sysdig entre autres a établi une liste de 29 outils de sécurité (gratuits et payants).
Nous en décrivons trois dans ce chapitre.

Docker bench security

Docker offre un script intéressant qui analyse la configuration sur une machine hôte en fonction de best practices : Docker-bench-security (Figure 15). Pour le lancement du script et des étapes pour corriger les avertissements, vous pouvez vous rendre sur https://www.digitalocean.com/community/tutorials/how-to- audit- docker- host- security- withdocker bench-for-security-on-ubuntu-16-04.
Nous nous basons sur des points de ce script pour mettre en place notre infrastructure Docker locale.

Sysdig Secure

La compagnie Sysdig propose son produit Sysdig Secure qui permet de réaliser des audits de sécurité, une gestion des vulnérabilités, des scans d’images Docker, des analyses de performances et de conformité, des opérations forensiques (par exemple : reproduction d’intrusions, fuite de données). Vous trouvez plus d’informations sur https://sysdig.com/products/secure/.
Vous pouvez leur demander une version Cloud ou logicielle (installation sur un serveur), les prix variant en fonction du contexte d’utilisation. D’après leur site, il faut souscrire pour un minimum d’une année. Nous ne testons donc pas ce logiciel dans ce travail.

Sysdig et Sysdig Inspect

Le logiciel open-source gratuit Sysdig Inspect rend possible l’analyse des captures de performances, du trafic et de la sécurité de conteneurs Docker effectuées au préalable par l’outil Sysdig, qui peut être installé sur une machine hôte ou exécuté dans un conteneur. Plus d’informations sur :
• https://sysdig.com/opensource/inspect/
• https://github.com/draios/sysdig/wiki/How-to-Install-Sysdig-for-Linux (installation de Sysdig)
• https://github.com/draios/sysdig-inspect/
Ce logiciel ne permet à priori pas d’effectuer un contrôle d’image Docker « en temps réel », avant le lancement de celle-ci. De plus, nous sommes obligés de posséder des fichiers de captures générés par sysdig, donc les analyses sont faites par après. Ceci est utile tout-de-même pour effectuer des analyses forensiques sur les conteneurs qui sont exécutés sur un hôte Docker et résoudre des problèmes éventuels.

Anchore Engine

L’outil Anchore Engine est un outil personnalisable pour analyser des images Docker, leur contenu et leurs potentielles vulnérabilités, à partir de règles (policies) par défaut ou définies par l’utilisateur. Ces images sont contrôlées dans un registre ou avant qu’elles soient déployées dans des conteneurs. Nous ne testons pas en détail cet outil, par manque de temps, mais il peut se révéler pratique pour posséder des images saines. Pour installer l’outil, veuillez vous référer à https://github.com/anchore/anchore-engine. La documentation se trouve sur

Implications légales

Le traitement de données personnelles (et sensibles) est, de nos jours, un sujet très important et récurrent et il est soumis aux lois de protection des données.

Principes de base de protection des données

Comme indiqué par exemple par le Centre National de Recherche Scientifique (CNRS), il existe sept principes de base qui doivent être pris en compte lors d’un traitement des données :
• Finalité
• Proportionnalité
• Pertinence des données
• Conservation
• Sécurité / confidentialité
• Transparence
• Respect du droit des personnes

Finalité

Les données recueillies doivent être traitées uniquement pour satisfaire les objectifs légitimes déterminés au moment de la collecte. (Engel, 2018)

Proportionnalité et pertinence des données

Les données doivent être « nécessaires pour leur finalité […] adéquates, pertinentes et non excessives au regard des objectifs poursuivis. » (CNRS, 2018)25

Conservation des données

Il est possible de distinguer deux périodes : la conservation, durant laquelle les données sont accessibles en consultation et l’archivage des données, durant laquelle les données sont stockées ailleurs dans l’entreprise et ne sont en principe plus utilisées. Les durées définies peuvent varier selon les lois. (Engel, 2018)

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela rapport-gratuit.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières
Résumé
Liste des figures
Liste des tableaux
Avant-propos
Remerciements
Liste des abréviations
Glossaire
1. Introduction
1.1. Contexte
1.2. Objectifs / étapes
2. Etat de l’art de Docker
2.1. Principes de Docker
2.1.1. Containers
2.1.1.1. Machines virtuelles vs. containers
2.1.2. Docker Images
2.1.2.1. Fonctionnement
2.1.3. Services Docker
2.1.4. Docker Engine
2.1.5. Registres d’images Docker
2.2. Versions de Docker
2.2.1. Community Edition
2.2.2. Enterprise Edition
2.3. Outils et méthodes Docker
2.3.1. Docker Swarm
2.3.2. Docker Compose
2.3.3. Docker Hub
2.3.4. Docker Store
2.3.5. Docker Cloud
2.3.6. Docker Machine
2.3.7. Docker Bench Security app
2.4. Standards / best practices
2.4.1. Taille des images Docker
2.4.2. Persistance des données
2.4.3. Fichier .dockerignore
2.4.4. Sécurité
3. Analyse des risques
3.1. Infrastructure
3.1.1. Surcharge de ressources
3.1.2. Utilisation du stockage
3.1.3. Panne / disfonctionnement
3.2. Sécurité
3.2.1. Menaces / failles possibles
3.2.1.1. Kernel et hôte Docker
3.2.1.2. Authenticité des images
3.2.1.3. Container breakout
3.2.1.4. Surcharge des ressources (déni de service)
3.2.1.5. Man-in-the-Middle
3.2.1.6. ARP Spoofing
3.2.1.7. Crédenciales et Docker secrets
3.2.1.8. Modification de données
3.2.1.9. Accès à des volumes de données non-autorisés
3.2.1.10. Fuite de données vers l’extérieur
3.2.1.11. Accès non-autorisé aux résultats d’analyse
3.2.2. Solutions d’analyse / protection
3.2.2.1. Docker bench security
3.2.2.2. Sysdig Secure
3.2.2.3. Sysdig et Sysdig Inspect
3.2.2.4. Anchore Engine
3.3. Implications légales
3.3.1. Principes de base de protection des données
3.3.1.1. Finalité
3.3.1.2. Proportionnalité et pertinence des données
3.3.1.3. Conservation des données
3.3.1.4. Sécurité et confidentialité
3.3.1.5. Transparence
3.3.1.6. Respect du droit des personnes
3.3.2. Lois concernées
3.3.3. Anonymisation et pseudonymisation
3.3.4. Conditions d’utilisation des données
3.3.5. Fuite ou modification non-autorisée de données
3.3.6. Sanctions en cas de non-respect des lois
4. Choix effectués
4.1. Méthodologie / planification
4.2. Technique (matériel)
4.3. Technique (logiciel)
5. Résultats
5.1. Architecture générale
5.2. Installation Docker et mode Swarm
5.3. Exécution de conteneurs (Service web)
5.3.1. Création de base d’un service Docker
5.4. Quotas RAM
5.4.1. Définition d’un quota dans le service Web
5.4.2. Test d’exécution avec limite RAM
5.4.2.1. Fonctionnement normal
5.4.2.2. Stress test
5.5. Quotas CPU
5.5.1. CFS scheduler
5.5.2. Real-time
5.5.3. Définition d’un quota CPU (service Web)
5.5.4. Tests d’exécution (CFS scheduler)
5.5.4.1. Fonctionnement normal
5.5.4.2. Stress test
5.5.5. Conclusion
5.6. Réseau Docker pour conteneurs
5.6.1. Définitions
5.6.2. Création d’un nouveau réseau
5.6.3. Définition du réseau à utiliser (service Web)
5.6.4. Tests de comparaison
5.6.5. Conclusion
5.7. Scheduler / queue Docker swarm
5.7.1. Processus de gestion des services et tâches
5.7.2. Filtres
5.7.3. Stratégies
5.7.4. Conclusion
5.8. Interface web cliente
5.9. Registre Docker interne privé
6. Conclusion
6.1. Bilan technique
6.2. Améliorations futures / recommandations
6.3. Problèmes rencontrés
6.4. Respect du cahier des charges
6.5. Conclusion personnelle
Références
Annexe I : Cahier des charges
Annexe II : Product backlog
Annexe III : PV séance kick-off 02.10.2018
Annexe IV : PV séance 2 10.10.2018
Annexe V : PV séance 3 17.10.2018
Annexe VI : PV séance 4 24.10.2018
Annexe VII : PV séance 5 31.10.2018
Annexe VIII : PV séance 6 06.11.2018
Annexe IX : PV séance 7 13.11.2018
Annexe X : PV séance 8 21.11.2018
Annexe XI : Liste de commandes Dockerfile
Déclaration sur l’honneur.