Qu’est-ce que la sécurité des conteneurs ?

L’utilisation des conteneurs a connu une croissance exponentielle au cours des dernières années. Bien que les technologies de conteneurs existent depuis des décennies, c’est le lancement de Docker en 2013 qui a rendu plus pratique pour les organisations l’adoption d’un modèle de développement et d’exploitation axé sur les conteneurs.

Cette croissance s’accompagne de risques en termes de sécurité. Avec des millions d’images disponibles parmi lesquelles choisir, la sécurisation des conteneurs est une discipline à part entière. Il existe de nombreuses couches de sécurité qui s’appliquent aux conteneurs, telles que :

• L’image du conteneur et le logiciel contenu

• L’interaction entre le conteneur, le système d’exploitation hôte et les autres conteneurs de l’hôte

• Le système d’exploitation de l’hôte

• Les référentiels de stockage et de mise en réseau des conteneurs

• L’environnement d’exécution, souvent dans des clusters Kubernetes

Chaque couche méritant un guide à part entière, le présent guide se concentre sur le premier point : l’image et votre code. Une seule image de conteneur peut contenir des centaines, voire des milliers, de vulnérabilités, ce qui peut exposer votre organisation à des incidents de sécurité (comme une brèche) et à une perte de productivité (due au temps nécessaire pour trier et évaluer les vulnérabilités à mesure que le nombre d’images utilisées augmente).

Qu’est-ce que la sécurité des conteneurs ?

Si la sécurité des applications relevait traditionnellement de la responsabilité d’équipes de sécurité spécialisées, par la manière dont les conteneurs sont aujourd’hui définis et construits, cette responsabilité incombe de plus en plus souvent aux équipes DevSecOps et aux développeurs.

Ce transfert de la responsabilité, ainsi que la vitesse à laquelle les conteneurs peuvent être mis à jour et déployés, nécessite une méthodologie de sécurité pratique allant bien au-delà de l’analyse de vos conteneurs dans le CI et du respect des meilleures pratiques en matière d’image pour traiter une analyse qui révèle des centaines de vulnérabilités.

Nous avons précédemment créé un guide pour la sécurité des conteneurs avec Docker. Pour plus de conseils pratiques, consultez nos 3 étapes pratiques pour sécuriser une image de conteneur. Dans ce billet, nous présenterons les pratiques DevSecOps que les organisations utilisent pour créer des conteneurs d’exécution et des images de conteneurs plus sûrs. Nous présenterons également les outils techniques, tels que Snyk Container, Snyk IaC et notre partenariat avec Sysdig, qui fournissent une sécurité complète des conteneurs, du développement à l’exécution.

Pourquoi la sécurité des conteneurs est-elle importante ?

La sécurité des conteneurs est importante car l’image du conteneur contient tous les composants qui, à terme, exécuteront votre application. Si des vulnérabilités se cachent dans l’image du conteneur, le risque et la gravité potentiels des problèmes de sécurité survenant pendant la production augmentent. À cette fin, il est normal que vous souhaitiez également surveiller la production. Même si vous créez des images sans vulnérabilités ni privilèges élevés, vous devez tout de même surveiller ce qui se passe durant l’exécution.

Présentation de la sécurité des conteneurs dans différents écosystèmes

Sécurité des conteneurs dans Docker

L’immense base d’utilisateurs de Docker, qui contient des dizaines de millions d’utilisateurs et des centaines de milliards d’extractions d’images, montre que la conteneurisation change la façon dont sont créées les applications. La responsabilité de la sécurité est de plus en plus transférée aux développeurs. Il est important d’analyser les images Docker avant de les pousser vers Docker Hub ou d’autres registres afin de détecter et de corriger les vulnérabilités contenues dans les paquets Linux, les permissions des utilisateurs, les configurations réseau, les outils open source ou la gestion des accès. Une telle analyse peut vous aider à mettre en lumière et à corriger les problèmes de vulnérabilité de votre application et de votre infrastructure avant leur livraison.

Sécurité des conteneurs dans Kubernetes

Kubernetes propose une myriade de contrôles de sécurité pour sécuriser vos clusters, charges de travail et conteneurs. Il est important de noter que Kubernetes nécessite une auto-configuration, aucun des contrôles de sécurité n’étant configuré lorsque vous déployez Kubernetes. En outre, si Kubernetes propose des contrôles et des fonctionnalités pour aider à créer un cluster sécurisé, les configurations de sécurité par défaut ne sont souvent pas suffisantes. Le déploiement de charges de travail en toute sécurité nécessite une bonne connaissance de Kubernetes. Consultez notre page sur les meilleures pratiques de sécurité de Kubernetes pour en savoir plus.

Sécurité des conteneurs dans GKE

Le moteur Google Kubernetes (GKE) fournit de nombreux outils destinés à sécuriser les charges de travail. Il est judicieux d’adopter une approche stratifiée de la sécurité GKE en configurant des fonctions de sécurité telles que les contrôles d’accès, les charges de travail, et autres. GKE peut être exécuté en mode standard, où vous gérez l’infrastructure sous-jacente, et en mode pilote automatique, où GKE provisionne et gère l’infrastructure. L’intégration de Snyk Container avec Kubernetes permet aux clients de sécuriser les charges de travail sur GKE, en mode standard ou autopilote, de découvrir les vulnérabilités à la fois dans les images de conteneurs et dans le code d’application, et d’analyser vos configurations Kubernetes pour détecter d’éventuels problèmes.

Sécurité des conteneurs dans AKS

À l’instar de GKE, Microsoft Azure Kubernetes Service (AKS) est doté de solides fonctionnalités de sécurité, telles que l’intégration à Azure Policy et des mises à jour/correctifs rapides et constants. Cependant, il nécessite un processus semi-manuel pour mettre à niveau les composants du cluster vers des versions plus récentes, et exige que les politiques réseau soient activées lors de la création du cluster. Comme pour GKE, Snyk peut analyser vos configurations et vos conteneurs Kubernetes, et activer la surveillance automatique lorsque vous déployez des ressources AKS.

Sécurité des conteneurs dans EKS

Amazon Elastic Kubernetes Service (Amazon EKS) dispose par défaut d’un ensemble solide de fonctionnalités de sécurité et fonctionne selon le modèle de responsabilité partagée d’AWS - qui définit qui est responsable des différents éléments de la sécurité des conteneurs. En général, AWS est responsable de la sécurité « du » cloud, tandis que vous (le client), êtes responsable de la sécurité « dans » le cloud.  Comme pour les autres options Kubernetes mentionnées ci-dessus, Snyk s’intègre facilement à Amazon EKS et Amazon Elastic Container Registry (Amazon ECR), pour analyser vos configurations Kubernetes et vos conteneurs, et permettre une surveillance automatisée lorsque vous déployez sur Amazon EKS.

5 meilleures pratiques pour la sécurité des conteneurs

À un niveau élevé, on distingue cinq étapes clés pour la création d’une image de conteneur sécurisée. Nous allons les examiner plus en détail afin de comprendre comment cette approche peut créer des images de conteneur sécurisées :

1. Sécurisez votre code et ses dépendances.

2. Commencez par une image de base minimale issue d’une source fiable.

3. Gérez toutes les couches entre votre image de base et votre code.

4. Utilisez la gestion des accès.

5. Sécurisez l’infrastructure des conteneurs.

1. Sécurisez votre code et ses dépendances.

La conteneurisation constitue un moyen de livrer plus rapidement des applications natives du cloud, et c’est probablement l’une des raisons pour lesquelles vous créez des conteneurs en premier lieu. Si les conteneurs ont élargi le sens du code des applications, le code reste toutefois la zone la plus directement contrôlée par les développeurs. Les dépendances open source peuvent facilement éclipser la quantité de code propriétaire, il est donc important de mettre en œuvre une analyse intégrée avec des outils d’analyse de la composition des logiciels (SCA) et de tests de sécurité des applications statiques (SAST) pour automatiser le processus d’analyse du code et des dépendances. Il est également possible d’analyser les conteneurs pour détecter les problèmes directement dans les commits et les référentiels Git, ce qui correspond probablement mieux au processus de développement.

2. Commencez par une image de base minimale issue d’une source fiable.

Si la taille est importante en termes de portabilité et de rapidité des téléchargements, elle réduit également le nombre d’éléments mobiles susceptibles d’héberger des vulnérabilités. Idéalement, chaque image de conteneur devrait contenir votre code et le nombre minimum de paquets supplémentaires nécessaires à l’exécution d’une application. En pratique, cependant, vous serez en présence d’un grand nombre d’applications et devrez trouver un terrain d’entente pour rendre les images de conteneur gérables.

De nombreux fournisseurs dignes de confiance hébergent des images de base de conteneurs pour vous permettre de sélectionner une image de base. Docker Hub est de loin le plus populaire, avec plus de 3,8 millions d’images disponibles, plus de 7 millions de référentiels et quelque 11 milliards d’extractions chaque mois. Certaines sont des images Docker officielles publiées par Docker sous la forme d’un ensemble de référentiels de solutions Docker open source et immédiates. Docker propose également des images de haute qualité qui sont directement gérées par des éditeurs vérifiés. Les directives de Docker concernant ces éditeurs vérifiés constituent un excellent point de départ pour définir vos propres meilleures pratiques en matière d’images de conteneurs.

S’il est facile d’aller sur Docker Hub et de trouver des images accessibles au public qui correspondent à votre cas d’utilisation, il convient toutefois de prêter attention à leur provenance. Si elles proviennent du programme Official Images de Docker ou que vous pouvez en vérifier la source et le contenu avec un outil tel que Notary pour la vérification des signatures numériques, vous disposerez d’un certain niveau d’assurance qualité.

3. Gérez toutes les couches entre l’image de base et votre code.

Les images de base nécessitent quelques considérations spécifiques : vous héritez de tout ce qui se trouve dans l’image de base lorsque vous construisez votre propre image par-dessus. Même en commençant avec une image mince, il est probable que vous devrez ajouter des outils et des bibliothèques, en plus de votre code et des installations nécessaires pour que tout fonctionne. Tous ces éléments doivent être contrôlés afin de détecter d’éventuelles vulnérabilités.

La bonne nouvelle, c’est que vous pouvez contrôler directement ces couches intermédiaires. Il est néanmoins important de définir les priorités sur lesquelles vous concentrez votre attention durant le développement, les tests et le déploiement en production. Vous pouvez avoir besoin de différents outils à chaque étape, mais lorsque les images sont mises en production, vous devez supprimer tout ce qui n’est pas absolument nécessaire.

En commençant par une base minimale et en n’ajoutant que les outils nécessaires, il est facile de supprimer par la suite ces outils en les retirant simplement du Dockerfile et en les recréant, ou en utilisant desbuilds en plusieurs étapes pour regrouper toutes ces étapes dans un processus de build unique et automatisé. Vous pouvez également découvrir des vulnérabilités dans les outils et les paquets de support qui sont installés au niveau de la couche intermédiaire, mais qui peuvent être ignorés si les images de production n’incluent pas tous ces éléments supplémentaires. Consultez notre article de blog pour connaître d’autres meilleures pratiques relatives aux builds en plusieurs étapes.

4. Utilisez la gestion des accès.

Dans le contexte des conteneurs, l’accès signifie la possibilité pour un utilisateur donné d’exécuter une opération spécifique sur une ressource de conteneur donnée. Les activités typiques relèvent des opérations de création, lecture, mise à jour ou suppression (CRUD). Les spécificités de la gestion des accès dépendent de la plateforme de conteneurs. Par exemple, dans Kubernetes, les utilisateurs vivent en dehors du cluster, ce qui signifie que les administrateurs doivent gérer les identités en dehors du cluster à l’aide de certificats TLS, OAuth2 ou d’autres méthodes d’authentification.

Les secrets et l’accès au réseau doivent fonctionner selon le principe du moindre privilège. L’accès des administrateurs doit être limité à l’infrastructure du build. Pour empêcher un conteneur d’avoir un accès complet à toutes vos ressources, vous devez attribuer des rôles et des responsabilités spécifiques aux conteneurs, puis utiliser des outils destinés à faciliter, faire appliquer et surveiller ces rôles.

5. Sécurisez l’infrastructure des conteneurs.

Outre la sécurisation de l’image du conteneur ou du conteneur en exécution, il est également nécessaire de gérer la pile d’infrastructure nécessaire à l’exécution des conteneurs, depuis un registre de conteneurs, comme Docker Hub, jusqu’à l’orchestration de la production avec Kubernetes.

Les registres de conteneurs étant conçus pour favoriser la collaboration en créant un lieu sécurisé de stockage et de partage des conteneurs, ils portent en eux le potentiel d’introduire des vulnérabilités, des logiciels malveillants et des secrets exposés. Ils sont souvent dotés de fonctions de sécurité intégrées, et un protocole de sécurité tel que TLS doit toujours être utilisé lors de la connexion à un registre.  De même, Kubernetes inclut des outils pour créer et appliquer des contrôles de sécurité au niveau du cluster et du réseau. Pour plus d’informations, consultez notre article sur la sécurité des registres de conteneurs.

Les conteneurs doivent toujours être exécutés sur un système ou un service cloud sécurisé. Dans le cas d’un service, des contrôles d’accès basés sur les rôles (RBAC) doivent être utilisés pour accéder au registre.

Un autre point : les attaquants concentrent leur attention plus tôt dans le pipeline CI/CD, alors ne négligez pas la sécurisation de ces premières étapes de développement. Lorsque vous créez des applications et des conteneurs, il est important d’analyser le code avant de l’utiliser dans une application et avant tout déploiement. En outre, il est essentiel d’utiliser le principe du moindre privilège (POLP) et d’automatiser les vérifications et les contrôles de sécurité au sein du pipeline de développement.

Utiliser Snyk Container pour la sécurisation des conteneurs

Lorsque les vulnérabilités de conteneurs se comptent par millions, détecter, prioriser et corriger ces vulnérabilités peut devenir une tâche accablante pour les développeurs. Snyk Container s’affranchit du bruit des rapports de vulnérabilité habituels en détectant et en corrigeant ensemble les vulnérabilités des applications et des conteneurs, et ce, même si vous n’avez pas accès au code source original exécuté dans vos conteneurs.

Snyk Container recherche en permanence les nouvelles vulnérabilités, priorise les corrections en fonction du contexte et de l’exploitabilité, découvre les problèmes dans les dépendances open source et associe les vulnérabilités à des commandes Dockerfile afin de faciliter l’introduction des corrections par les développeurs. Snyk Container a été utilisé pour réaliser plus de 130 millions de tests de conteneurs en 2021 ; 56 millions de vulnérabilités ont été corrigées par les utilisateurs de Snyk Container.

En collaborant avec Snyk Infrastructure as Code pour sécuriser la configuration des conteneurs, Snyk Container s’intègre à de nombreuses plateformes Kubernetes, notamment AKS et GKE, aux registres de conteneurs tels que Docker Hub, GCR et Quay, et aux systèmes d’exploitation de base des conteneurs, notamment Amazon Linux et Ubuntu, et bien d’autres encore. L’analyse intégrée des vulnérabilités aide les développeurs à identifier et à utiliser des images de base minimales appropriées et automatise le processus de mise à jour pour éliminer rapidement les vulnérabilités.

Snyk Container, comme le reste de la plateforme Snyk, adopte une approche centrée sur le développeur et supporte la culture DevSecOps. Il s’intègre à l’IDE, analyse les requêtes d’extraction avant de les fusionner, donne des conseils relatifs aux corrections et applique des tests automatisés aux pipelines CI/CD. Une fois les conteneurs en exécution, il surveille en permanence les déploiements pour détecter toute exposition à des vulnérabilités existantes ou nouvellement divulguées. Les alertes sont ensuite envoyées par Slack, Jira, e-mail ou par d’autres moyens, afin d’aider les DevSecOps à identifier et à corriger rapidement les vulnérabilités.

Comment le partenariat Snyk-Sysdig permet de sécuriser l’exécution des conteneurs

Le retour précoce sur la qualité d’image de Snyk Container peut aider à éliminer 70 % voire plus des vulnérabilités, mais 30 % des vulnérabilités d’exécution ne sont pas prises en compte. Celles-ci peuvent représenter des centaines de vulnérabilités sur des milliers de conteneurs et de clusters. Détecter et corriger ces vulnérabilités peut être une tâche colossale. Il est difficile de savoir quels paquets sont utilisés dans un conteneur en exécution, et quelles vulnérabilités affectent ces paquets lors de l’exécution. Les équipes chargées de la sécurité et des opérations responsables de la gestion des environnements actifs doivent découvrir les vulnérabilités avant d’impliquer les équipes de développement pour les corriger. Toutefois, les développeurs manquant d’expertise en matière de systèmes, la détection et la correction des problèmes par les outils de détection des vulnérabilités existants peut prendre des mois.

Snyk s’est associé à Sysdig pour aider à résoudre les problèmes dans les environnements d’exécution en donnant plus de contexte sur les facteurs qui affectent l’environnement d’exécution. Ce partenariat crée une solution de sécurité qui couvre l’ensemble du processus DevOps. La combinaison des plateformes Snyk et Sysdig sécurise tout, du code dans l’environnement du développeur à l’infrastructure qui fait fonctionner le cluster.

Consultez ce billet d’annonce pour en savoir plus sur la façon dont le partenariat Snyk-Sysdig étend la sécurité des conteneurs à l’environnement d’exécution.

Synthèse de la sécurité des conteneurs

La sécurité des conteneurs est un vaste sujet ; même en se limitant à la sécurité des images de base, de nombreux défis sont à prendre en considération. Voici quelques points clés à garder à l’esprit pour sécuriser vos images :

• Commencez par des images de base provenant d’un fournisseur de confiance et utilisez des signatures numériques pour vérifier l’authenticité.

• Optez pour des images de base minimales contenant uniquement les paquets du système d’exploitation de base et le framework de votre choix, puis développez-les à partir de là.

• Dès le début et souvent, recherchez d’éventuelles vulnérabilités dans les images.

• Effectuez des analyses tout au long du cycle de vie des logiciels : sur le bureau, dans le CI, dans les images stockées dans les registres et dans les conteneurs qui s’exécutent dans vos clusters.

• Choisissez des outils d’analyse qui, au lieu de se contenter d’un simple rapport sur les vulnérabilités de type feuille de calcul, fournissent des conseils sur les mesures d’atténuation, recommandent des images de base, donnent aux développeurs des informations pour corriger les problèmes et offrent la flexibilité dont vous avez besoin pour définir vos barrières de sécurité.

Si vous souhaitez sécuriser vos images de conteneurs tout au long de leur cycle de vie, Snyk Container automatise la sécurité des conteneurs en privilégiant les développeurs, en offrant le bon équilibre entre sécurité et productivité, afin que vous puissiez construire des images plus sûres et des conteneurs en exécution.

Glossaire de la sécurité des conteneurs

• Analyse des conteneurs : processus consistant à détecter des vulnérabilités dans les conteneurs en analysant les paquets et les dépendances dans une image de conteneur.

• Surveillance des conteneurs : la collecte de métriques et le suivi de la santé des applications et architectures conteneurisées.

• Kubernetes : un système open source développé à l’origine par Google pour orchestrer des applications conteneurisées dans un cluster.

• K8s : une abréviation de Kubernetes.

• Docker : la plateforme de conteneurs la plus populaire au monde. Docker a démocratisé les outils et les processus de création et d’exécution de conteneurs, permettant aux développeurs d’utiliser facilement ces technologies.

• Dockerfile : un fichier texte contenant les configurations nécessaires pour construire une image Docker.

• Google Kubernetes Engine (GKE) : GKE est l’offre de service de gestion de Google permettant d’exécuter des charges de travail Kubernetes sur Google Cloud.

• AKS : le service Kubernetes géré de Microsoft Azure. Au départ, il s’agissait d’un service plus générique, Azure Container Service, puis il a évolué vers AKS lorsque Kubernetes est devenu la plateforme d’orchestration de conteneurs dominante.

• AWS EKS : le service Kubernetes géré par Amazon Web Service pour l’exécution de charges de travail Kubernetes sur AWS. AWS EKS peut être utilisé seul ou avec d’autres services comme AWS Fargate. AWS Fargate masque essentiellement toute l’infrastructure Kubernetes, permettant ainsi aux utilisateurs de se concentrer uniquement sur leurs propres pods Kubernetes.

• Image de conteneur : un fichier statique qui contient un ensemble d’instructions pour créer un conteneur en exécution.

• Registre de conteneurs : un outil de gestion et de référentiel d’images de conteneurs qui facilite le stockage et le partage des images de conteneurs.

• Runtime de conteneur : un logiciel qui crée, exécute et gère les conteneurs sur un système d’exploitation hôte.

• Shift left : une culture et un ensemble d’outils qui intègrent la sécurité dans les workflows des développeurs.

• DevSecOps : abréviation de développement, sécurité et opérations, DevSecOps est une approche qui automatise la sécurité dans le cycle de vie de livraison des logiciels.

FAQ sur la sécurité des conteneurs