Skip to main content

La sécurité dans le registre de conteneurs

Écrit par

Michael Komraz

Security in The Container Registry small

21 février 2019

0 minutes de lecture

L’un des principes fondamentaux de Snyk est ce que nous appelons « developer first ». Dans notre vision du produit, cela signifie s’intégrer au flux de travail et aux outils existants des développeurs grâce à des intégrations performantes, afin que la prise en charge de la sécurité par les développeurs soit aussi fluide que possible.

Autrement dit, nous voulons permettre de gérer la sécurité là où se trouvent déjà les développeurs, par exemple :

  • Dans l’IDE, par exemple avec notre plug-in IntelliJ, lancé fin 2018

  • Au niveau de Git, où les développeurs peuvent ouvrir des pull requests pour corriger les problèmes existants et en prévenir de nouveaux

  • Lors de la phase de build, qui, en tant que point de contrôle, constitue généralement un complément davantage axé DevOps à Git

  • Dans les environnements PaaS et d’exécution, par exemple avec nos intégrations Pivotal pour droplet, buildpack et broker

  • Dans les outils de gestion de projet et de messagerie comme JIRA, Slack et d’autres

Couches de conteneurs et risques cachés

Les conteneurs (au sens large du terme) comptent parmi les évolutions les plus marquantes du secteur informatique et présentent de nouveaux défis en matière de sécurité, tant du côté du développement que des opérations. Par exemple, dans l’ancien monde des serveurs et des machines virtuelles, de nombreuses équipes d’entreprise utilisent une méthode d’« image de référence » pour permettre aux équipes opérationnelles de contrôler la couche de base (système d’exploitation et packages) de leurs applications. La façon dont les images Docker sont créées, distribuées et utilisées rend irréaliste l’application de cette méthode par les équipes travaillant dans le cloud, car les images de conteneurs comportent de nombreuses couches dont la provenance ou la robustesse n’est pas toujours claire.

La solution de gestion des vulnérabilités des conteneurs de Snyk analyse les images Docker en inspectant les packages du système d’exploitation et les principaux binaires, puis en comparant les résultats à notre base de données exclusive sur les vulnérabilités. Elle permet ainsi de visualiser les dépendances directes et indirectes cachées dans les couches de l’image. Dans la capture d’écran ci-dessous, Snyk descend jusqu’à cinq couches pour signaler un problème de gravité élevée :

Capture d’écran du terminal signalant une vulnérabilité de déni de service de gravité élevée dans libidn11 et affichant sa chaîne de dépendances de paquets dans le Dockerfile.

La détection des risques n’est qu’une première étape : le défi suivant consiste à les corriger directement dans le flux de travail. C’est pourquoi nous proposons des conseils de correction dans l’outil. Il est également essentiel de s’appuyer sur des informations fiables et de limiter les faux positifs, ce que permet la base de données sur les vulnérabilités de Snyk, qui fait figure de référence dans le secteur.

Mais un développeur soucieux de la sécurité ne devrait pas s’arrêter là. L’étape suivante présente un autre défi : publier une image potentiellement compromise dans votre registre de conteneurs. Effectuée manuellement avec une surveillance étroite de la sécurité, cette opération peut être inefficace ; automatisée sans les garde-fous nécessaires, elle peut compliquer considérablement le contrôle opérationnel et les audits. L’approche de Snyk vise à automatiser le processus en s’appuyant sur de bonnes pratiques de sécurité, comme le montre l’exemple suivant.

Hello-ACR-world

Nous avons créé cette application de démonstration pour analyser toutes les images Docker publiées dans Azure Container Registry (ACR). Plutôt que de ralentir le cycle de développement, nous intégrons l’analyse et les conseils de correction au flux ACR Tasks. Dans le fichier .yaml ci-dessous, on voit qu’entre les étapes BUILD et PUSH standard d’ACR Tasks, nous avons ajouté un script qui recherche les vulnérabilités à la fois dans l’image et dans l’application (binaires) :

Éditeur de code en thème sombre affichant un pipeline de build YAML avec des commandes d’image Docker, des tests de vulnérabilités Snyk, des variables d’environnement et une étape de push.

Le processus est configuré pour interrompre l’étape PUSH en présence de vulnérabilités du système d’exploitation de gravité élevée et/ou de vulnérabilités de l’application de gravité moyenne à élevée. Dans ce cas, l’analyse échoue et l’étape PUSH ne peut pas avoir lieu. Cette courte vidéo présente le processus plus en détail :

À retenir

Le modèle des conteneurs comporte des risques supplémentaires en matière de sécurité et de conformité. La solution de gestion des vulnérabilités des conteneurs de Snyk permet de détecter et de corriger les vulnérabilités directes et — plus important encore dans ce cas — indirectes de nos images de conteneurs. Nous pouvons également automatiser davantage nos processus DevOps en ajoutant Snyk comme point de contrôle avant la publication d’une image non corrigée dans notre registre de conteneurs. Associées aux capacités de Snyk en matière de gestion du code source, de CI/CD et de PaaS, ces étapes constituent une solution complète et convaincante pour les conteneurs.

N’hésitez pas à nous indiquer quels registres de conteneurs vous utilisez déjà et comment vous automatisez vos processus pour concilier efficacité et sécurité !

La sécurité des conteneurs, pensée pour les développeurs

Snyk détecte et corrige automatiquement les vulnérabilités dans les images de conteneurs et les workloads Kubernetes.