Snyk Container et Cloud Native Buildpacks : la sécurité des applications cloud-native comme il se doit

Vous exécutez des microservices dans des conteneurs ? Félicitations ! C’est une étape importante pour répondre aux besoins de l’entreprise et livrer des applications à vos clients le plus rapidement possible. Mais comment atténuer les risques potentiels liés à l’accélération des déploiements logiciels ? Rien de plus simple : avec Snyk.

Associé à un outil de build qui crée des images de conteneurs conformes à OCI, Snyk Container vous aide à atténuer ce risque et à vous concentrer sur l’essentiel : offrir une expérience client exceptionnelle. Voyons comment cela fonctionne.

Différence entre les images Docker et les images conformes à OCI

Pour garantir que tous les environnements d’exécution de conteneurs puissent lancer les images produites par n’importe quel outil de build, la communauté open source des conteneurs a créé l’Open Container Initiative (OCI) afin de définir des normes sectorielles pour les formats d’image et les environnements d’exécution de conteneurs. À partir d’une image OCI, tout environnement d’exécution de conteneurs qui implémente laspécification OCI Runtime peut extraire l’image et l’exécuter dans un environnement isolé.

Vous avez très probablement déjà entendu parler de Docker et vous vous demandez peut-être quelle est la différence entre les images OCI et les images Docker. Aujourd’hui, la réponse est « pas grand-chose ». Il existe encore quelques anciennes images Docker qui précèdent les spécifications OCI. Officiellement, elles sont au format Docker v1 et ne sont pas compatibles avec le schéma Docker v2, qui a été donné à l’OCI et a servi de base aux spécifications OCI. Mais ces images v1 remontent à 2017. Aujourd’hui, presque tous les registres de conteneurs, les plateformes Kubernetes et les environnements d’exécution de conteneurs reposent sur les spécifications OCI. C’est notamment le cas du moteur Docker, de Docker Hub et d’autres outils et produits Docker.

Pourquoi est-ce important, vous demandez-vous peut-être ? Parce que ces spécifications ouvertes ont permis à d’autres groupes d’innover dans la création de conteneurs. Et comme tous produisent des images conformes à OCI, vous pouvez les exécuter partout et utiliser des outils de sécurité comme Snyk Container pour les protéger. En définitive, vous souhaitez probablement que vos équipes de développement se concentrent sur le code de l’application, plutôt que sur la structure du Dockerfile, qu’elles ne passent des heures à vérifier quelles bibliothèques open source utiliser ou éviter, ou qu’elles parcourent les milliers de tags d’images sur Docker Hub pour trouver l’image de base à utiliser. Découvrons une méthode permettant de créer des conteneurs directement à partir du code source : Cloud Native Buildpacks.

Cloud Native Buildpacks : du code source aux conteneurs en une étape

Cloud Native Buildpacks (CNB) transforme le code source de votre application en images OCI entièrement conformes, exécutables sur n’importe quel cloud. Mieux encore, cette solution prend en charge tous les langages de programmation les plus répandus. Problème des conteneurs résolu, avec contrôle, conformité et facilité de maintenance !

Si vous avez déjà utilisé Heroku, la plateforme PaaS Pivotal (aujourd’hui VMware Tanzu Application Service) ou le projet open source associé, Cloud Foundry, vous avez déjà vu une solution similaire aux buildpacks. Il suffit d’envoyer votre code à ces services, qui se chargent de le regrouper dans un environnement d’exécution adapté. Les CNB offrent la même expérience pour les images OCI. Le développeur écrit son code, puis les CNB compilent toutes les dépendances de l’application et regroupent tout ce dont elle a besoin dans une image de conteneur.

Fonctionnement de Cloud Native Buildpacks (source : vmware Tanzu Developer Center)

Exemple

1$ pack build pasapples/pbs-demo-image:latest --builder paketobuildpacks/builder:base --publish --path ./target/springbootemployee-0.0.1-SNAPSHOT.jar

Que construisent exactement les Cloud Native Buildpacks ?

Comme tout outil de création d’images, Cloud Native Buildpacks crée un ensemble de couches du système de fichiers contenant l’environnement d’exécution, votre application et toutes ses dépendances, ainsi que les métadonnées dont le moteur de conteneurs a besoin pour savoir comment démarrer l’application. Voici les informations sur les couches de l’exemple ci-dessus, obtenues avec la commande docker image history :

1$ docker image history pasapples/pbs-demo-image:latest
2IMAGE      CREATED    CREATED BY   SIZE  COMMENT
35d29940d2e52   41 years ago            68kB
4<missing>  41 years ago            46.3MB
5<missing>  41 years ago            10B
6<missing>  41 years ago            7.05MB
7<missing>  41 years ago            451kB
8<missing>  41 years ago            2.09MB
9<missing>  41 years ago            7.23MB
10<missing>  41 years ago            3.04MB
11<missing>  41 years ago            140MB
12<missing>  41 years ago            214B
13<missing>  41 years ago            6.69MB
14<missing>  41 years ago            2.27MB
15<missing>  41 years ago            398kB
16<missing>  41 years ago            6.51MB
17<missing>  41 years ago            7B
18<missing>  41 years ago            745B
19<missing>  41 years ago            987kB
20<missing>  41 years ago            63.2MB

Si l’horodatage datant de 41 ans vous intrigue, il sert à permettre des builds reproductibles. Vous trouverez plus d’informations à ce sujet ici : Time Travel with Pack

Avec l’outil dive, nous pouvons explorer plus en détail le contenu des couches. Dans la fenêtre en haut à gauche de la capture d’écran ci-dessous, nous avons sélectionné l’avant-dernière couche de l’image (dans dive, les couches sont listées de bas en haut, alors que la sortie du build ci-dessus les présente dans l’ordre inverse). À droite, nous examinons le contenu de cette couche, qui comprend des fichiers JAR d’une application Springboot dans notre image OCI. CNB a assemblé tout cela pour nous à partir de notre code source.

Sécurité des images de conteneurs OCI avec Snyk Container

Snyk Container détecte les vulnérabilités dans les conteneurs et les charges de travail Kubernetes tout au long du cycle de développement logiciel, en analysant toute image conforme à OCI, y compris celles créées avec Cloud Native Buildpacks ou d’autres outils de build. Mais Snyk ne se contente pas de dresser la liste des vulnérabilités présentes dans vos conteneurs : Snyk Container fournit des conseils qui vous aident à créer rapidement des conteneurs plus robustes et moins vulnérables. Et grâce à nos fonctionnalités améliorées de détection des images de base, nous pouvons fournir les mêmes conseils qu’auparavant, réservés aux utilisateurs qui incluaient un Dockerfile !

Correction automatisée des images de base avec Snyk Container

Renforcez vos capacités de sécurité en permettant aux développeurs d’éliminer rapidement de nombreuses vulnérabilités en passant à une image de base plus sécurisée ou en reconstruisant l’image lorsque celle-ci est obsolète.

Lors de l’analyse de ces images OCI, Snyk peut détecter l’image de base sur laquelle vos images ont été construites et vous suggérer des images de base comportant peu de vulnérabilités, comme illustré ci-dessous.

Quelle image de base pouvons-nous utiliser, ou avons-nous récemment mise à jour, pour notre conteneur OCI ?

Ces recommandations d’images de base sont disponibles quel que soit le moment ou l’endroit où vous analysez vos images au cours de leur cycle de vie. L’exemple ci-dessus montre une image stockée sur Docker Hub ; ci-dessous, nous avons analysé une image avec l’interface de ligne de commande Snyk, une méthode également applicable à l’analyse de vos pipelines CI. Snyk peut suggérer des images de base comportant peu de vulnérabilités, comme illustré ci-dessous :

1$ snyk container test pasapples/pbs-demo-image
2
3Testing pasapples/pbs-demo-image...
4
5✗ High severity vulnerability found in openssl
6  Description: NULL Pointer Dereference
7  Info: https://snyk.io/vuln/SNYK-UBUNTU1804-OPENSSL-1089073
8  Introduced through: openssl@1.1.1-1ubuntu2.1~18.04.5, ca-certificates@20180409, openssl/libssl1.1@1.1.1-1ubuntu2.1~18.04.5
9  From: openssl@1.1.1-1ubuntu2.1~18.04.5
10  From: ca-certificates@20180409 > openssl@1.1.1-1ubuntu2.1~18.04.5
11  From: openssl/libssl1.1@1.1.1-1ubuntu2.1~18.04.5
12  and 1 more...
13  Fixed in: 1.1.1-1ubuntu2.1~18.04.9
14
15...
16
17Organization:  pas.apicella-41p
18Package manager:   deb
19Project name:  docker-image|pasapples/pbs-demo-image
20Docker image:  pasapples/pbs-demo-image
21Platform:      linux/amd64
22Base image:    ubuntu:bionic-20200403
23Licenses:      enabled
24
25Tested 93 dependencies for known issues, found 57 issues.
26
27Base Image          Vulnerabilities  Severity
28ubuntu:bionic-20200403  49           0 critical, 0 high, 16 medium, 33 low
29
30Recommendations for base image upgrade:
31
32Minor upgrades
33Base Image Vulnerabilities  Severity
34ubuntu:bionic  25           0 critical, 0 high, 3 medium, 22 low
35
36Major upgrades
37Base Image  Vulnerabilities  Severity
38ubuntu:rolling  17           0 critical, 0 high, 2 medium, 15 low

Vulnérabilités de l’application et du conteneur réunies

Vous n’avez pas toujours accès au code source d’origine exécuté dans vos conteneurs, mais les vulnérabilités de vos dépendances de code restent importantes. Snyk peut détecter et surveiller les dépendances open source des langages de programmation les plus répandus dans le cadre de l’analyse des conteneurs.

La couche de base par rapport aux dépendances open source, clairement affichées pour une image OCI CNB.

Aidez les développeurs à se concentrer sur les vulnérabilités présentant le plus de risques

Snyk vous aide à vous concentrer facilement sur les problèmes prioritaires, plutôt que de devoir en examiner des centaines un par un. Ignorez ou excluez les vulnérabilités provenant des images de base et appuyez-vous sur des indicateurs de risque, comme le niveau de maturité des exploits et la configuration non sécurisée des charges de travail, pour aider vos équipes à faire le tri parmi les alertes souvent trop nombreuses des rapports sur les vulnérabilités des conteneurs.

Snyk Container n’est qu’un élément de la plateforme Snyk Cloud Native Application Security, conçue pour aider les développeurs à détecter et à corriger les vulnérabilités des applications cloud-native. Essayez-la dès aujourd’hui.