Récapitulatif de SnykLaunch : recommandations d’images de base personnalisées
4 avril 2023
0 minutes de lectureParmi les nouvelles fonctionnalités passionnantes présentées aujourd’hui à SnykLaunch figuraient les recommandations d’images de base personnalisées (CBIR). En bêta ouverte depuis fin 2022, CBIR est déjà utilisé par plusieurs organisations. À l’approche de sa disponibilité générale, nous avons enrichi ses fonctionnalités pour offrir davantage de flexibilité et intégrer des capacités d’automatisation sans intervention, permettant ainsi aux utilisateurs d’exploiter CBIR dans leurs pipelines CI/CD.
Les recommandations d’images de base personnalisées étendent les puissantes recommandations d’images de base au cœur de Snyk Container, en les proposant aux organisations et aux entreprises qui suivent des workflows DevOps plus avancés. Que vous disposiez d’équipes dédiées à la sélection, à la création, à la personnalisation et au renforcement de la sécurité de vos images de base sélectionnées ou « de référence », ou que vous partiez simplement d’une image qui ne figure pas parmi les images officielles populaires, cette fonctionnalité vous sera très utile.
Il existe de nombreux workflows pour créer et livrer vos applications conteneurisées, mais plusieurs grandes étapes sont communes : le choix de l’image de base, la phase de build (ajout de bibliothèques courantes, de composants et de fichiers de projet), puis le déploiement.
Pourquoi recommander des images de base ?
Le choix d’une image de base commence souvent par une image « Docker Official » correspondant au langage de programmation utilisé pour écrire le projet. Pour une application Python, nous choisirions une image Python ; pour une application Java, une image Java.
Au cours du cycle de livraison des images de conteneur, il est essentiel de réduire au minimum les risques liés aux vulnérabilités. De nombreux outils peuvent détecter les packages vulnérables dans vos images et suggérer des versions corrigées. Par exemple, l’image de base node:14.0.0 contient plus d’un millier de vulnérabilités. Malheureusement, de nombreux outils ne proposent que des recommandations pour chaque vulnérabilité, comme ici.
Dans cet exemple, nous voyons des versions qui corrigeraient certaines vulnérabilités, mais nous ne savons pas clairement ce que nous devons faire. En corriger une ? Toutes les corriger ?
Les recommandations d’images de base vous aident à trouver de meilleures images pour démarrer. Plutôt que de corriger les vulnérabilités une par une, vous pouvez en éliminer des groupes entiers en un seul clic. Ici, une mise à niveau mineure vers node:14.21.3 réduit le nombre de vulnérabilités de 64 %, tandis que le passage à la variante bullseye-slim élimine presque toutes les vulnérabilités, à l’exception de quelques-unes de faible gravité.
Des workflows DevOps avancés
Dans certaines organisations, l’équipe de développement d’applications est responsable de la création et de la maintenance des images de conteneur. D’autres adoptent des workflows plus avancés, fondés sur une répartition des tâches : une équipe plateforme crée des images de base internes sélectionnées, ou « de référence », que les développeurs peuvent utiliser. L’équipe plateforme choisit les images de base de départ, puis configure et crée des images de base de conteneur internes conformes aux normes de l’entreprise. Celles-ci peuvent inclure des bibliothèques courantes, le respect de conventions de nommage ou de balisage, ainsi que le renforcement de la sécurité pour atténuer les vulnérabilités des images de base.
Cette répartition des responsabilités permet aux développeurs de se concentrer sur les applications qu’ils écrivent, sans avoir à corriger les images de base.
Voyons comment fonctionne ce workflow avancé avec CBIR.
Cycle de vie des images de base personnalisées
Équipes plateforme et sécurité
Dans ce modèle de responsabilités partagées, l’équipe plateforme est chargée de sélectionner les images de départ et de créer les images de base personnalisées que les développeurs utiliseront. Elle doit automatiser et sécuriser une chaîne d’approvisionnement évolutive d’images de conteneur à partir desquelles les développeurs pourront créer leurs images, tout en donnant à l’équipe sécurité une visibilité complète sur l’état des images de base afin qu’elle puisse prioriser les corrections. Cette visibilité crée une boucle de rétroaction qui permet aux équipes de livrer des images plus sécurisées. À noter que l’équipe plateforme peut toujours s’appuyer sur la logique standard de recommandation d’images de base pour créer ses images de base personnalisées.
Une fois créée, une image de base personnalisée peut être importée dans Snyk pour être surveillée, par les méthodes déjà disponibles : l’interface de ligne de commande, les outils CI/CD et l’API, ou l’interface Snyk. Dès qu’une image est surveillée par Snyk Container, vous pouvez la définir comme « image de base personnalisée » et, si vous le souhaitez, l’utiliser dans les recommandations. Snyk peut détecter automatiquement les versions plus récentes en fonction du versionnage sémantique, de la date de balisage ou de modèles de nommage personnalisés.
Ce processus peut également être automatisé via l’API. Désactiver l’option « Utiliser dans les recommandations » est utile lorsqu’une image a été remplacée par une autre version et que vous ne souhaitez plus qu’elle soit proposée en remplacement.
Développeurs
Lorsqu’un conteneur est dérivé d’une image de base personnalisée ou qu’il en utilise une avec FROM, les recommandations sont proposées en fonction de la famille d’images. Si le Dockerfile ayant servi à créer l’image est inclus, des options de mise à niveau en un clic sont également disponibles, comme dans cet exemple. Le développeur utilise ici mybaseimage:1.0, qui présente 185 vulnérabilités. La version la plus récente, la 6.0, en compte moins, et le développeur peut rapidement ouvrir une pull request pour effectuer la mise à niveau. De plus, des pull requests peuvent être créées automatiquement pour les images dérivées d’images de base personnalisées lorsqu’une nouvelle version de l’image de base est publiée.
L’utilisation des images de base personnalisées sélectionnées par l’équipe plateforme élimine le bruit que les développeurs doivent trier. Ils peuvent ainsi se concentrer sur les packages qu’ils ont ajoutés aux conteneurs — manuellement ou à l’aide de gestionnaires de packages — ainsi que sur leur application. L’essentiel, c’est qu’ils n’ont pas à s’en préoccuper.
Automatisez votre chaîne d’approvisionnement de conteneurs
Comme indiqué plus haut, de nouvelles API permettent de désigner les images de base surveillées comme images de base personnalisées et d’enregistrer des schémas de versionnage personnalisés pour nommer vos conteneurs. Vous pouvez ainsi nommer vos images comme vous en avez l’habitude, tout en bénéficiant de recommandations personnalisées.
Ces API vous permettent d’intégrer le balisage d’images personnalisé et les recommandations d’images de base personnalisées à vos workflows automatisés, tout en donnant à vos développeurs les moyens de se concentrer sur la livraison de logiciels plus sécurisés.
Consultez également notre documentation sur les recommandations d’images de base personnalisées pour en savoir plus sur cette fonctionnalité.
Essayez dès aujourd’hui !
Les recommandations d’images de base personnalisées de Snyk Container sont actuellement disponibles pour les clients de l’offre Enterprise. Elles devraient être proposées ultérieurement aux autres offres, y compris l’offre gratuite. Avant la disponibilité générale, contactez votre responsable de compte ou ouvrez un ticket auprès du support pour activer cette fonctionnalité dans votre organisation et prendre le contrôle de vos workflows de chaîne d’approvisionnement de conteneurs.
Pour découvrir la démo, regardez l’enregistrement à la demande de SnykLaunch.
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.