Une meilleure façon de consommer des applications tierces

Les applications tierces, telles que les bases de données populaires (MySQL, Postgres, Clickhouse, etc.), les serveurs (NGINX, Envoy, etc.) et les outils de développement (ArgoCD, Spark, Prometheus, etc.), sont des éléments essentiels pour le développement de logiciels modernes. Traditionnellement, les développeurs installent manuellement ces applications au-dessus d'un système d'exploitation Linux complet ou téléchargent une image de conteneur à partir de sources Internet publiques pour acquérir l'application. Toutefois, cette méthode pose un certain nombre de problèmes :

1. L'installation manuelle de paquets d'applications tierces à partir de sources Internet non fiables annule souvent les efforts de renforcement menés par les équipes chargées de la plateforme.

2. Les images d'applications tierces open source provenant de registres tels que Docker sont basées sur des distributions non renforcées, ce qui introduit un volume important de CVE et élargit la surface d'attaque déjà importante de votre conteneur.

Dans les deux cas, les développeurs n'ont pas le contrôle de l'arbre de dépendance de l'application, ce qui signifie qu'ils sont soit 1) entièrement dépendants des mainteneurs en amont pour les correctifs, soit 2) qu'ils assument le fardeau de forker et de patcher eux-mêmes le code tiers, ce qui accroît la complexité.

En bref, l'approche traditionnelle de la consommation d'images d'applications tierces est fragile et met en évidence le besoin urgent d'une meilleure solution. Une solution qui permette aux développeurs de tirer toutes les applications dont ils ont besoin, en toute sécurité et de manière évolutive dès le départ. Chez Chainguard, nous résolvons ce problème avec nos Application Images, une suite de plus de 1 100 images de conteneurs entièrement construites à partir des sources, minimales et conçues pour réduire la surface d'attaque de vos conteneurs. Et nos images d'application sont simples à utiliser - les développeurs peuvent les intégrer directement dans leurs piles de développement existantes et continuer à avancer.

Pour mieux illustrer les avantages des images d'application de Chainguard, examinons plus en détail le statu quo et les défis qu'il pose.

Durcis à l'avant, CVEs à l'arrière

Les équipes chargées des plateformes, héros méconnus des meilleures pratiques DevOps modernes, consacrent souvent des efforts considérables au durcissement des distributions de base traditionnelles des systèmes d'exploitation. Chez Chainguard, nous qualifions souvent ces distros de systèmes d'exploitation " d'évier de cuisine " parce qu'ils ont été construits pour la largeur, prenant en charge les ordinateurs portables, les serveurs, les VM, et plus encore ; cependant, ces distros ne sont généralement pas optimisées pour les conteneurs et le développement cloud-native parce qu'elles 1) incluent des composants excédentaires qui ne sont pas nécessaires pour construire et exécuter un conteneur (élargissant la surface d'attaque) et 2) sont livrées dans des versions figées, " stables " qui inhibent la capacité des mainteneurs à déployer chaque mise à jour logicielle et correctif de CVE. Par conséquent, les équipes chargées des plateformes doivent effectuer elles-mêmes le travail de renforcement afin de garantir que les développeurs puissent créer des applications à partir d'une base plus sûre et plus sécurisée.

C'est dans les applications tierces que cet équilibre délicat commence à se rompre. Une fois que ce système d'exploitation de base est distribué en aval, nos clients nous ont dit que les développeurs d'applications installent manuellement des composants d'applications ou superposent des images d'applications open source à l'image de base à partir de sources non fiables, réduisant ainsi à néant le travail acharné de l'équipe chargée de la plateforme.

Bien que cette approche soit pratique, elle entraîne de nombreuses conséquences négatives pour les ingénieurs de la plateforme et les développeurs d'applications :

• Conteneurs gonflés : L'ajout de paquets supplémentaires au système d'exploitation de base, que ce soit manuellement ou par le biais d'images d'application de cuisine, signifie une plus grande surface d'attaque à défendre.

• Manque de contrôle : Les développeurs n'ont pas le contrôle de l'arbre de dépendance de l'application, ce qui signifie qu'ils doivent soit s'appuyer sur l'amont pour les correctifs, soit corriger manuellement les images eux-mêmes, assumant ainsi la complexité de la maintenance d'un code tiers.

• Maintenance et frais généraux : Si les ingénieurs décident de gérer le code de l'application tierce, ils courent un risque supplémentaire de rupture lors de l'application des correctifs et de l'intégration des applications dans leur pile de développement.

Ces défis sont vrais même pour les images open source d'applications tierces populaires comme Airflow. Voici un exemple illustratif d'Airflow, dont l'image open source contient 79 CVE (dont 15 CVE critiques/élevés) pour une taille d'image de 405 Mo et 612 paquets.

La solution moderne de Chainguard : Des images d'application minimales et spécifiques

Pour résoudre ces défis pour nos clients, Chainguard a construit plus de 1100 images d'applications spécifiques à partir de la source de manière minimale, éliminant ainsi la surface d'attaque et les CVE. Et surtout, ces images sont faciles à intégrer dans votre pile de développement existante et à mettre en œuvre rapidement, car Chainguard prend en charge la gestion de l'image et la remédiation des CVE pour que vous n'ayez pas à le faire. Comme nos images de base, les images d'application de Chainguard n'incluent que les composants nécessaires à la construction et à l'exécution de vos applications, avec une attestation totalement transparente sous la forme de SBOM à la construction et de signatures de code via Sigstore.

Pour démontrer ce point, prenons par exemple l'image Airflow de Chainguard, qui est illustrée ci-dessous. L'image Airflow de Chainguard ne comporte que 6 CVE, dont un seul critique, comparé à la répartition 79/15 de l'image OSS, et est significativement plus petite avec 270 Mo et 400 paquets (contre 405 Mo et 612 paquets).

Nous constatons des résultats similaires - réduction de la taille et des CVE - sur l'ensemble des images d'application de notre catalogue, ce qui vous permet de vous concentrer sur l'essentiel : créer la meilleure expérience possible pour vos clients. Nous continuons d'étoffer notre catalogue, afin d'aider nos clients à évoluer et à proposer des produits de qualité à leurs utilisateurs.

Réduire votre charge de maintenance

L'un des avantages les plus convaincants du modèle Chainguard pour les images d'applications tierces est la réduction de la charge de maintenance imposée aux développeurs, en particulier lorsqu'il s'agit de posséder le code d'une application tierce. Les approches traditionnelles de la consommation d'images d'applications obligent les équipes d'ingénieurs à assumer la responsabilité non seulement de leur code d'application de première partie, mais aussi de la distribution de base, de ses dépendances Linux et de toutes les dépendances de leurs applications.

Avec Chainguard, les clients peuvent se décharger de la gestion et de la remédiation CVE, Chainguard prenant en charge la distribution Linux de base, les dépendances Linux et les dépendances applicatives. Nous soulignons la responsabilité partagée entre Chainguard et nos clients dans le diagramme ci-dessous :

Chainguard Application Images : L'approche moderne

Prêt à améliorer vos pratiques de développement d'applications ? Explorez les images d'application de Chainguard dès aujourd'hui et contactez-nous pour en savoir plus sur la façon dont elles peuvent transformer vos flux de travail.