Une instance proxy pour vos binaires : indispensable !

Au cours des vingt dernières années, les composants Open Source, portés par une communauté Open Source dynamique, ont radicalement transformé notre façon de développer des logiciels. Une instance « proxy » d’un Binary Repository peut faire bien plus que de simplement mettre en cache des artefacts. Cet article détaille plusieurs opportunités, des bonnes pratiques de sécurité jusqu’aux techniques de déploiement avancées applicables aux conteneurs et à Kubernetes.

Un peu d’histoire

Dans les années 2000, chaque entreprise développait ses propres bibliothèques et frameworks applicatifs, essentiellement en interne, avec parfois des résultats médiocres en termes de qualité et de performance. Dans l’écosystème Java, Log4j est sorti pour la première fois en 2001, le framework Spring en 2003, puis nous avons littéralement assisté à une avalanche de bibliothèques pour tous les langages et tous les usages.

Au fil des années, le nombre d’artefacts embarqués dans nos applications n’a cessé de croître, tout comme le nombre de projets hébergés dans les dépôts publics, qui a augmenté de façon exponentielle.

source: https://mvnrepository.com/repos

Aujourd’hui, même les applications de démonstration les plus simples embarquent des dizaines de bibliothèques, directement ou de façon transitive. L’avènement des pratiques DevOps telles que l’Infrastructure-as-Code, les conteneurs et les microservices a multiplié par dix la quantité de binaires et de packages.

source: https://dzone.com/articles/use-a-binary-repository-manager-and-keep-up-with-d

Mettre en cache vos artefacts

Il est très courant qu’une machine de développeur ou un exécuteur de CI stocke des gigaoctets de données binaires, uniquement pour des bibliothèques mises en cache provenant de dépôts publics centraux tels que Maven Central, Docker Hub, le registre public NPM, le Python Package Index, etc. Pour des équipes conséquentes, le téléchargement de ces artefacts peut représenter une charge significative sur la bande passante Internet, ainsi que des secondes précieuses pour vos pipelines de CI.

La mise en cache des artefacts au sein de l’entreprise est donc devenue une pratique largement répandue, dès les débuts de l’intégration continue. Les deux options d’entreprise pour assurer la mise en cache d’artefacts pour tous les langages de programmation courants sont JFrog Artifactory et Sonatype Nexus.

La mise en cache des artefacts peut vous sauver la mise à bien des égards…

Quelle entreprise n’a jamais subi une perte d’accès à Internet pendant quelques heures ? Parfois, le problème vient de l’extérieur : les dépôts publics eux-mêmes peuvent connaître des interruptions de service. Par exemple, Quay.io a connu de sérieuses difficultés le 19 mai 2020, de 3h à 23h EDT. D’un point de vue plus prévisible, le passage d’Internet au « HTTPS partout » a contraint chacun à ajuster les paramètres de ses dépôts.

Dans certains cas, l’absence d’une seule bibliothèque peut tout casser ! Souvenez-vous du chaos left-pad de 2016, provoqué par un seul développeur qui a dépublié ses packages, impactant, à grande échelle, des milliers de projets…

Plus récemment, Docker Hub a annoncé une mise à jour de ses conditions d’utilisation, avec à la fois :

• une limite de débit : 100 pulls par tranche de 6 heures pour les utilisateurs non authentifiés, aucune limite pour les comptes payants
• une limite de rétention : les images sans activité depuis 6 mois sont automatiquement supprimées

Si ces mesures sont tout à fait compréhensibles pour maintenir un service gratuit et de qualité pour la majorité des utilisateurs, la limite de débit peut impacter les entreprises qui exécutent des charges de travail en conteneurs. Déployer des environnements applicatifs plusieurs fois par jour avec des images de bases de données (PostgreSQL, Redis, etc.), des images de messagerie (Kafka, etc.) peut rapidement dépasser cette limite.

Là encore, si vous utilisez une instance Proxy pour vos images Docker en provenance d’Internet, vous n’avez plus aucun souci à vous faire…

Si vous avez seulement besoin de mettre en proxy des images Docker et d’autres artefacts cloud-native (charts Helm, OPA, Singularity, etc.), vous pouvez désormais le faire avec le registre Harbor, gradué par la CNCF. La récente version 2.1 inclut la fonctionnalité Proxy Cache, permettant à Harbor d’agir comme un registre en cache relais (pull through cache) pour des registres tels que DockerHub et Harbor.

Vulnérabilités et gouvernance

Votre entreprise peut faire bien plus que de simplement mettre en cache des artefacts avec une instance proxy pour vos binaires. Vous pouvez aider votre équipe Sécurité à mieux dormir la nuit en appliquant les principes du Shift-Left, tels que le scan de vulnérabilités sur les composants Open Source (OSS).

Prenons d’abord un peu de recul et réfléchissons à la part de code Open Source au sein de nos applications métier : 80 %, 90 %, plus encore ? Je pense qu’il faut désormais raisonner en ces termes concernant le ratio code Open Source / code développé en interne dans nos applications. À un certain stade, il est appréciable de pouvoir concentrer davantage d’efforts sur l’expérience utilisateur ou les fonctionnalités métier, plutôt que sur la gestion des transactions ou l’interopérabilité avec des systèmes externes, etc. Mais, revers de la médaille, nous externalisons effectivement les préoccupations techniques de nos applications vers la communauté Open Source. Dans la plupart des cas, le code écrit par la communauté, puis éprouvé sur des milliers d’applications, est bien plus fiable et performant que n’importe quel code écrit en interne selon une approche propriétaire… dans la plupart des cas… et c’est précisément là que la « confiance » compte plus que tout !

L’exemple ci-dessous, tiré de Snyk.io, montre l’évolution des vulnérabilités de niveau élevé dans la bibliothèque jackson-databind (fasterxml), très largement utilisée pour le JSON et les API REST. L’équipe de développement a fourni un effort considérable en début d’année pour corriger toutes les vulnérabilités : les versions récentes 2.10.x et 2.11.x ne présentent aucune vulnérabilité connue.

source: https://snyk.io/vuln/maven:com.fasterxml.jackson.core%3Ajackson-databind

Pendant des années, des applications ont été mises en production avec de graves vulnérabilités. L’intégration des préoccupations de sécurité au sein du DevOps a donné naissance au Manifeste DevSecOps et aux approches Build-Security-In, suscitant une prise de conscience croissante des vulnérabilités, tant au sein de la communauté Open Source qu’au sein des organisations. Depuis quelques années, l’implication forte des entreprises de sécurité envers l’Open Source a rendu les composants Open Source Software (OSS) de plus en plus sûrs. Dans le même temps, des comités consultatifs de sécurité ont également fleuri sur les sites web de la plupart des plateformes et éditeurs logiciels, dans un souci de transparence.

Il faut comprendre que le suivi des vulnérabilités dans les actifs logiciels ne peut être réalisé manuellement, comme le montre l’exemple de jackson-databind, même pour une seule application. Il existe en effet plusieurs outils pour scanner les vulnérabilités des composants OSS, y compris les images Docker, parmi lesquels :

• Anchore Engine, un service centralisé d’inspection, d’analyse et de certification des images de conteneurs
• Firewall, intégré à la plateforme Sonatype Nexus, agissant comme un contrôle périmétrique pour les chaînes d’approvisionnement logiciel
• Gitlab, incluant une étape Secure intégrée et contextuelle du cycle de vie DevOps pour le scan des conteneurs et des dépendances
• Snyk, permettant aux développeurs de détecter et corriger en continu les vulnérabilités dans les bibliothèques Open Source et les conteneurs
• Trivy d’AquaSecurity, désormais intégré à Harbor comme scanner par défaut, un scanner de vulnérabilités simple et complet pour les conteneurs et autres artefacts
• Twistlock, désormais intégré à l’offre Prisma Cloud de PaloAlto Networks, une plateforme de sécurité moderne pour les charges de travail cloud-native
• Xray, intégré à la plateforme JFrog DevOps, un produit d’analyse d’impact universel renforçant la sécurité des artefacts, la sécurité des conteneurs et la conformité des licences OSS

Des règles basées sur divers facteurs de risque peuvent être appliquées pour bloquer le téléchargement ou mettre en quarantaine les artefacts vulnérables, directement à la « source » du Proxy.

Segmentation réseau

Certains d’entre vous mettent peut-être déjà en cache des artefacts pour certains langages, Maven et NPM étant certainement les plus utilisés, sur la même instance que celle utilisée pour publier vos artefacts privés, fièrement construits dans vos pipelines de CI.

D’un point de vue sécurité, mélanger artefacts publics et privés sur la même instance n’est clairement pas le meilleur choix.

Une instance Proxy et une instance binaire privée ont très peu de points communs :

• Hébergement : zone DMZ vs. zone réseau interne
• RBAC : accès anonyme vs. utilisateurs et tokens authentifiés
• Activité quotidienne : essentiellement en lecture seule vs. taux d’écriture élevé
• Nettoyage : aucun vs. rétention incrémentale basée sur la promotion des builds
• Niveau de confiance : liste blanche de packages et versions de confiance vs. promotion des artefacts vers la production

Toutes ces considérations peuvent vous amener vers un schéma tel que celui ci-dessous :

Conclusion

Une instance proxy pour les binaires devrait être un incontournable pour toute entreprise. Avec le bon choix d’outils et une configuration de déploiement pertinente, vous pouvez considérablement renforcer à la fois votre indépendance vis-à-vis des dépôts / registres publics et le niveau de sécurité de vos applications… le tout sans grever votre budget 😉.

Certaines techniques avancées peuvent être utilisées pour :

• Renforcer le niveau de sécurité dans des environnements protégés sans dégrader l’expérience développeur
• Combiner la promotion d’artefacts et les identités pour sécuriser les déploiements vers des clusters Kubernetes
• …

Pour aller plus loin, découvrez notre consulting DevOps.