MARGO

Actualité

Kubernetes & sécurité des conteneurs

Quelles sont les meilleures pratiques techniques pour éviter les failles de sécurité des conteneurs ?

Par Villeret Foyang Software Engineer

03/10/2019

Kubernetes est un système en open-source qui permet d’automatiser le déploiement, la mise à l’échelle et la gestion d’applications conteneurisées. En regroupant les conteneurs d’applications sous forme d’unités logiques, ce système en facilite à la fois la gestion et la découverte. Alors que ce mode d’accès aux ressources de calcul commence à devenir omniprésent du fait de sa vaste adoption par le marché, à laquelle s’ajoutent 15 années d’expérience de l’exécution de charges de travail en mode production auprès de Google, ce succès est contrebalancé par la découverte d’une quantité croissante de vulnérabilités au niveau des conteneurs. Dès lors, la sécurisation et le maintien de normes de conformité deviennent des enjeux extrêmement importants dans ces environnements. Nous évoquerons, dans cet article, la sécurité et les conteneurs de Kubernetes, en nous penchant plus précisément sur les types de solutions que privilégient aujourd’hui les grandes entreprises pour se prémunir contre les problèmes de sécurité visant les conteneurs, ainsi que les outils en open-source auxquelles elles accordent leur confiance. Quelles sont les meilleures pratiques techniques pour éviter les failles de sécurité des conteneurs ? Quels sont les outils en open-source disponibles pour détecter ces vulnérabilités ? C’est ce que nous allons voir.

 

Vulnérabilités de Kubernetes et des conteneurs

Avant d’aborder les stratégies employées par les entreprises pour déjouer les vulnérabilités, il convient de revenir un instant sur les types de failles les plus courants. Le recensement donné sur le site de CVE (Common Vulnerabilities Exposures) cite principalement les cas suivants :

  • Attaques par déni de service, ou DoS : elles permettaient auparavant à des utilisateurs habilités à adresser des demandes de modification au serveur d’API de Kubernetes d’envoyer un morceau de programme spécialement fabriqué qui consommait des ressources excessives lors du traitement, entraînant une attaque DoS sur le serveur d’API.
  • Faille des escalades de privilèges : permettait à tout utilisateur disposant du niveau d’accès requis d’exercer l’ensemble des privilèges d’administrateur sur la moindre unité de matériel informatique ou le moindre nœud exécuté sur un cluster Kubernetes. Il devenait alors possible à un pirate d’élever ses privilèges de manière à acquérir des droits d’administrateur complets sur n’importe quel nœud de calcul exécuté dans un « pod » Kubernetes, autrement dit un ensemble de nœuds partageant les mêmes ressources et le même réseau local.
  • Extraction de flux d’informations : permettait à un groupe de conteneurs partageant des ressources de stockage et de réseau identiques (pod) sur un nœud donné d’extraire les fichiers journaux depuis n’importe quel autre pod membre de ce nœud, dans la mesure où les requêtes de localisation des journaux de pod ne faisaient l’objet d’aucune vérification. Un attaquant distant pouvait alors exploiter cette faille pour afficher des informations sensibles via des journaux de pod théoriquement inaccessibles.

Ces quelques exemples ne représentent qu’une petite partie des vulnérabilités qui ont été identifiées, rendues publiques et ont fait l’objet de correctifs. Pour autant, chacun sait qu’entre la découverte d’une vulnérabilité, sa publication et l’établissement de rapports et de correctifs, les pirates informatiques ont tout loisir de mener une multitude d’offensives telles que des attaques inter-conteneurs en phase de déploiement, ou encore la prise de contrôle de systèmes à des fins malveillantes.

 

Comment répondre à ces vulnérabilités au niveau de l’entreprise ?

Les entreprises et services informatiques disposent aujourd’hui d’une pluralité d’options pour prémunir leur organisation contre les faiblesses de leurs logiciels. En règle générale, ce mesures consistent à mettre en place une nouvelle méthodologie de travail et à automatiser les procédures de sécurité.

Modification des processus pour plus d’agilité dans le domaine de la sécurité

L’une de ces opportunités consiste à mettre sur pied une équipe de développement, de sécurité et d’opérations (« DevSecOps ») chargée de mettre en œuvre la sécurité durant l’intégralité de la phase de conception des applications. Certes, les entreprises aimeraient pouvoir confier la sécurité à leurs équipes de développeurs ou de DevOps, mais ce domaine exige des connaissances très spécifiques, telles qu’une bonne connaissance des réseaux ou une solide expertise de la remédiation aux menaces, dont la maîtrise échappe a priori à tout développeur. L’appréhension de l’ensemble du pipeline depuis la phase de conception jusqu’à l’exécution, ainsi que la garantie d’avoir sous la main une expertise technique de haut niveau, entrent donc systématiquement en ligne de compte. Dans une certaine mesure, une équipe de DevSecOps incite les équipes de sécurité à collaborer avec les équipes de DevOps pour mettre au point l’automatisation des processus de sécurité. De fait, ce mode d’organisation contribue à tenir les développeurs informés de la visibilité de la sécurité, des retours d’information et des menaces connues. Au final, la mise en place d’une DevSecOps permet d’instaurer entre les développeurs, DevOps et équipes de sécurité un langage commun qui favorise la compréhension mutuelle en termes d’application.

Automatisation

L’automatisation est le seul moyen d’harmoniser le rythme de progression entre les équipes de sécurité et de DevOps. La mise à l’échelle des conteneurs au niveau de l’entreprise ne peut se contenter de politiques et de listes de contrôle de sécurité statiques ; le pipeline a besoin de services de sécurité renforcés. Grâce à l’automatisation, il devient possible de déployer des conteneurs évolutifs et des politiques de conformité sécuritaire à une échelle massive. Pour automatiser un flux de travaux dans le pipeline alors que les conteneurs sont morcelés au niveau du réseau, les entreprises averties spécifient le mode de comportement et d’interaction des services au moment de l’exécution, afin de décider quelle politique de sécurité il convient d’appliquer pour les automatiser.

Pour que l’efficacité de la sécurité soit garantie à l’échelle d’une organisation, celle-ci doit s’automatiser jusqu’au stade où elle devient capable de générer des règles de sécurité de façon autonome, puis elle doit définir un vocabulaire commun permettant d’évoquer l’infrastructure en termes de code. Ainsi, la configuration doit, par exemple, être délivrée sous la forme d’un morceau de code source ou de sécurité en tant que code. Imaginez qu’une atteinte à la sécurité soit automatiquement détectée, consignée, corrigée, testée et déployée pendant que votre personnel informatique est en plein sommeil… Votre système pourrait alors se réparer lui-même, en rassemblant toutes les informations pertinentes pour découvrir si une attaque est survenue, ainsi que sa provenance et ce, sans perdre le moindre temps de disponibilité. Par ailleurs, l’automatisation de la sécurité signifie un temps moyen de réaction raccourci de plusieurs semaines à quelques jours, quelques heures, voire quelques minutes seulement, dans la mesure où le temps de déploiement par les développeurs est réduit.

 

Règles de bonne pratique en matière de sécurité des conteneurs

Si les années récentes nous ont appris quelque chose, c’est que les failles de sécurité informatique sont inévitables. Les vulnérabilités ont beau être signalées, cela n’empêche pas de nombreuses organisations de continuer à adopter le prochain produit, la prochaine mise à niveau ou le correctif suivant. « Cette fois-ci, c’est sécurisé pour de bon », espèrent-elles. Or, à ce jour, il n’en a jamais été ainsi. La seule manière de faire efficacement des affaires dans un monde où règne l’insécurité consiste à mettre en place des processus qui reconnaissent l’insécurité inhérente aux produits. Pour protéger les ressources des entreprises contre les pirates qui cherchent à tirer profit des vulnérabilités, et pour réduire leurs risques d’exposition, quels que soient les produits ou correctifs concernés, les organisations doivent mettre en œuvre des règles de bonne pratique en matière de sécurité. Examinons-en quelques-unes :

  1. Confiance et restriction

Ayez toujours à votre disposition des images réalisées à partir de sources fiables, via une authentification d’image par une signature numérique ou par le biais d’un système de stockage à registre privé. Ces images doivent être analysées afin d’évaluer les vulnérabilités courantes et connues (CVE), les configurations non sécurisées, les fuites d’informations d’identification, les droits d’accès insuffisants aux fichiers sensibles, la conformité aux normes sectorielles (PCI, NIST, SIC), ainsi que les licences de logiciels non prises en charge. Ce passage au crible doit permettre de déceler les vulnérabilités contenues dans toutes les couches de l’image, et non uniquement dans sa couche de base.

Cette analyse des images est indispensable, mais elle n’est encore pas suffisante : si les images des conteneurs sont immuables, ce n’est pas le cas de leur mode d’exécution. Lorsqu’un conteneur arrive en phase de production, il se peut que de nouvelles vulnérabilités soient découvertes, que les logiciels présentent des défauts, que des modifications soient intervenues dans les données et les droits d’accès, ou que des fuites de mémoire se soient produites. Les outils de contrôle de configuration automatisés sont alors capables de scanner l’ensemble de l’environnement Kubernetes afin d’évaluer sa conformité aux lignes directrices établies, telles que les évaluations comparatives ou « benchmarks » de Kubernetes.

  1. Inspection et sécurisation du réseau

Le réseau représente l’aspect le plus critique en matière de sécurité des conteneurs. Certaines capacités de protection telles que les pare-feu et mesures de sécurité au niveau des nœuds finaux doivent également être étendues aux conteneurs et à l’ensemble du trafic est-ouest. Kubernetes, de même que tout autre outil d’orchestration de conteneurs, repose sur une configuration de sécurité par défaut qu’il est généralement très important de passer en revue, comprendre et paramétrer en fonction des besoins.

  1. Réduction de la surface d’attaque au strict minimum

La surface d’attaque correspond à la somme des différents points à partir desquels un utilisateur non autorisé peut saisir des données ou les extraire de votre environnement. S’agissant des conteneurs, la surface d’attaque est généralement plus restreinte, dans la mesure où votre Docker vous permet de sélectionner une image de distribution allégée telle qu’Alpine, qui est conçue dans une perspective de sécurité, de simplicité et de performances des ressources. Sur ce type de conteneur, la surface d’attaque est réduite puisque seules les bibliothèques essentielles sont présentes.

 

Recommandations de sécurité en phase de pré-déploiement

Cette liste de meilleures pratiques de sécurité est loin d’être exhaustive et peut différer d’une organisation à l’autre d’après les exigences spécifiques rencontrées. Au demeurant, il est recommandé aux équipes DevOps d’observer certaines mesures de sécurité préalablement au déploiement, de manière à garantir la création d’images efficaces, protéger chaque nœud et prévenir les menaces telles que les configurations à risque, fuites d’informations d’identification ou droits inadéquats sur les fichiers sensibles. Citons notamment les recommandations et lignes directrices générales suivantes :

  • Isoler les conteneurs au moyen d’espaces-noms afin de prévenir les attaques par escalade de privilèges.
  • Limiter les capacités de Linux de manière à éviter l’exécution de processus en tant qu’utilisateur root. Pour les conteneurs dont les processus doivent obligatoirement être exécutés en tant qu’utilisateur racine à l’intérieur du conteneur, vous pouvez affecter à cet utilisateur un niveau de privilèges moins élevé.
  • Activer SELinux, qui est une version à sécurité renforcée de Linux mise au point par la NSA appliquant une politique de sécurité supplémentaire à tous les processus.
  • Activer le mode Secure Computing (seccomp), une fonctionnalité du noyau Linux destinée à restreindre les actions disponibles à l’intérieur du conteneur.
  • Configurer les Cgroups de manière à limiter une application à un ensemble spécifique de ressources.
  • Utiliser un système d’exploitation hôte réduit au minimum, en privilégiant des images minimales contenant uniquement les outils et bibliothèques systèmes indispensables à votre projet, afin de réduire la surface d’attaque au strict minimum.
  • Mettre à jour les correctifs du système.
  • Exécuter des tests de sécurité avec des comparatifs CIS.
  • Ne jamais insérer de code secret dans un fichier Docker.
  • Ne jamais transférer le port privilégié (n° 22).
  • Ne pas forcer la directive User.
  • Ne pas effectuer de copier/coller.
  • Utiliser une image de base digne de confiance.
  • Éviter les packages non indispensables.
  • Disposer d’images immuables reproductibles, pour éviter d’obtenir des résultats variables entre différentes exécutions.
  • Ne pas utiliser la « toute dernière » version en production. Dans le cas contraire, vous ne pourrez pas effectuer de déploiement régressif. Il n’est pas possible de revenir au « dernier niveau -1 ». Mieux vaut donc libeller vos images avec des balises porteuses de sens.

 

Outils de sécurité en open-source de Kubernetes

Bien que les outils disponibles dans le commerce proposent une protection et une visibilité à portée multivectorielle, certains projets en open-source continuent d’évoluer et de se doter de fonctionnalités de sécurité nouvelles. Voici quelques solutions à envisager pour les projets moins stratégiques en production :

  • Falco : Falco est un projet en open-source né de la volonté de comprendre le comportement des conteneurs et de protéger votre plateforme contre les activités malveillantes potentielles. Le moteur de règles peut détecter une activité anormale dans les applications, les conteneurs, l’hôte sous-jacent et la plateforme de conteneurs. Falco fait partie intégrante de l’architecture du moteur de réponse Kubernetes, qui traite les événements de sécurité en contrant les atteintes à la sécurité au moyen de réponses tactiques.
  • Istio : Istio crée un maillage de services pour gérer les communications, y compris le routage, l’authentification et le chiffrement, mais ce logiciel n’est pas conçu comme un outil de sécurité destiné à détecter les attaques et les menaces.
  • Anchore : Anchore est une solution d’analyse de conteneurs dotée de fonctions de génération de rapports et de mise en conformité sur la base de règles.
  • Clair : Clair est un projet en open-source qui procède à une analyse statique des vulnérabilités dans les conteneurs applicatifs.

 

Conclusion

La sécurité des conteneurs émerge parmi les préoccupations importantes, voire essentielles exprimées dans les enquêtes récentes, car elle concerne désormais la phase de production des services réels. Les entreprises prennent conscience de la nécessité de sécuriser le flux de travaux complet au sein de leur pipeline afin d’éviter de s’exposer à une diversité de menaces. À l’instar de n’importe quel autre logiciel, Kubernetes n’est pas à l’abri des incidents de sécurité. L’adoption massive des applications conteneurisées sur le marché ajoute la vulnérabilité des images et des conteneurs à la liste des problèmes de sécurité courants, ainsi qu’à celle des nouvelles menaces découvertes. Pour contrer ces failles, les entreprises averties doivent automatiser et rendre plus agiles leurs processus, garantir leur conformité par des meilleures pratiques de sécurité, sécuriser leur plateforme de déploiement et maîtriser les problèmes de sécurité à grande échelle.

 

 

Liens de référence :


Par Villeret Foyang Software Engineer
Conteneur
Kubernetes
Sécurité
Actualité

Le regard d’un DevOps sur le Paris Container Day

Les conférences rassemblent les développeurs et les passionnées de tech afin qu’ils discutent ensemble d’un thème ou d’une technologie en particulier. Durant une conférence, les intervenants introduisent des technologies innovantes et partagent leur feedback et expérience sur les technologies à la mode. A partir de là, un développeur peut choisir de s’ouvrir à des nouvelles technologies ou bien de refuser les quêtes secondaires que représentent ces conférences.

25/07/2018 Découvrir 
Actualité

Conteneurs : zoom sur une technologie qui révolutionne l'infrastructure

Dans un monde de plus en plus digitalisé, les challenges de la mise à l'échelle, la tolérance à la panne, l'évolutivité et la maintenabilité sont de plus en plus importants. Les conteneurs, combinés avec les patrons de conceptions, notamment l’architecture micro service, révolutionnent la manière de concevoir les systèmes informatiques pour mieux répondre aux exigences de la nouvelle ère digitale.

10/07/2018 Découvrir 
Actualité

Les Conteneurs au cœur de toutes les pensées

Le 26 juin dernier, professionnels, amoureux de l’orchestration ou des nouvelles technologies, experts ou encore entrepreneurs se sont rassemblés à Paris où a eu lieu le Paris Container Day. Retour sur la 3ème édition de cet événement tant attendu.

03/07/2018 Découvrir 
Actualité

Les Cookies, très utilisés, mais si peu compris

Lou Montulli, co-fondateur de Netscape et créateur du Text Web Browser Lynx, est un informaticien américain à l’origine de la balise Blink et aussi de la première Live Web Cam d’Internet. Il est aussi connu pour être l’inventeur des fameux Cookies HTTP.

26/04/2018 Découvrir