Suppression de docker.io/Bitnami

• L’équipe Bitnami a reporté au 29 septembre la suppression du catalogue public docker.io/bitnami
• Avant la suppression, plusieurs brownouts (blocage temporaire de certaines images) sont prévus pour aider les utilisateurs à s’adapter
• À l’avenir, les images de conteneurs et charts Helm de Bitnami seront déplacés vers Bitnami Secure Images (BSI), doté de solides fonctionnalités de sécurité, ou vers le registre Bitnami Legacy
• Les images BSI sont gratuites pour le développement et les tests, mais un abonnement payant est requis pour l’accès à l’ensemble des images et au support à long terme
• Face à l’évolution de la sécurité de la chaîne d’approvisionnement open source et des contraintes réglementaires, une transition depuis l’ancien modèle devient nécessaire

---

Calendrier de suppression du catalogue public Bitnami sur docker.io et guide de transition

Mise à jour

• Après avoir recueilli les avis de la communauté et évalué l’impact, l’équipe Bitnami a repoussé au 29 septembre 2024 la suppression du catalogue public docker.io/bitnami
• Avant la suppression du registre, trois brownouts (blocage temporaire de 24 heures de certaines images de conteneurs) sont prévus afin que les utilisateurs prennent conscience du changement
  • du 28 août à 08:00 UTC au 29 août à 08:00 UTC
  • du 2 septembre à 08:00 UTC au 3 septembre à 08:00 UTC
  • du 17 septembre à 08:00 UTC au 18 septembre à 08:00 UTC
• Pour chaque brownout, les images concernées seront annoncées le jour même
• À partir du 28 août, Bitnami ne distribuera plus ses images de conteneurs ni ses charts Helm sur Docker Hub dans le nouveau format (OCI)
• Le code source des conteneurs et des charts Helm continuera d’être fourni sur GitHub sous licence Apache 2.0

Ce qui change

• À partir du 28 août, Bitnami déplacera son registre OCI existant (charts et images) vers Bitnami Legacy, puis basculera vers de nouvelles images renforcées sur le plan de la sécurité

• Si vous utilisez les images actuelles, vous devrez modifier les chemins de pull d’images dans vos pipelines automatisés, vos miroirs internes et vos clusters Kubernetes pour pointer vers le nouvel emplacement

• Options disponibles pour les utilisateurs

  1. Migrer vers Bitnami Secure Images (BSI)
  2. Migrer vers le registre Bitnami Legacy (temporairement)

• Afin d’assurer la continuité du système et le maintien des fonctionnalités, la migration vers Bitnami Secure Images (BSI) est recommandée

• Avec BSI, les images renforcées améliorent la posture de sécurité et la capacité à répondre aux exigences de conformité

Migration vers Bitnami Secure Images (BSI)

• Certaines images BSI sont gratuites pour le développement et les tests, mais l’accès au catalogue complet, aux tags stables et aux versions avec support long terme est réservé aux abonnements payants
• Les abonnés BSI continueront de recevoir l’intégralité du catalogue d’images Bitnami basées sur Debian ainsi que les mises à jour
• La migration et la montée de version vers des images renforcées basées sur Photon Linux sont recommandées
  • Elles restent compatibles avec les images Debian existantes, et les charts Helm peuvent être utilisés de la même manière
• Principaux avantages des images basées sur Photon
  • Réduction majeure du nombre de CVE (dans certains cas, de plus de 100 à 0)
  • Prise en charge des diagnostics VEX et intégration des scores KEV/EPSS pour faciliter la gestion des vulnérabilités
  • UI/API en self-service avec de solides fonctions de reporting et de métadonnées
  • Prise en charge de charts Helm avancés, dont des charts distroless réduisant la surface d’attaque de 83 %
  • Possibilité de personnaliser les images construites dans une software factory conforme à SLSA 3 (standard de sécurité de la chaîne d’approvisionnement)
  • Fourniture d’un registre OCI privé et sécurisé dédié au client (sans contrainte de public/rate limit contrairement à Docker Hub)
  • Accès à plus de 90 images de VM au format OVA
  • Support entreprise pour le packaging et l’installation

Migration vers le registre Bitnami Legacy

• Comme solution provisoire, Bitnami propose aux utilisateurs existants le registre Bitnami Legacy
  • Il s’agit d’images dans un format d’archive non pris en charge (sans correctifs de sécurité, etc.)
  • Aucune disponibilité à long terme n’est prévue : accumulation rapide de vulnérabilités et obsolescence à craindre
  • En cas d’usage temporaire, il est recommandé de copier les images nécessaires vers votre propre registre
  • Fondamentalement, une transition rapide vers le nouveau système renforcé sur le plan de la sécurité (BSI) reste nécessaire

Pourquoi cette transition en matière de sécurité de la chaîne d’approvisionnement open source et de conformité

• Le principal contexte est l’évolution récente de l’écosystème open source et la forte hausse des paquets malveillants (plus de 245 000 cas entre 2019 et 2023 selon Sonatype)
  • Cela représente environ le double de l’ensemble des périodes précédentes
• Avec la croissance de l’écosystème IA/modèles, l’usage de l’open source augmente fortement → la surface d’attaque et les risques augmentent aussi
• Des réglementations comme le Cyber Resilience Act (UE) créent une obligation de démontrer la provenance et l’intégrité des logiciels open source
• Avec l’adoption de Bitnami Secure Images, Bitnami fournit aux organisations un environnement leur permettant de mettre en place plus facilement la sécurité de la chaîne d’approvisionnement et la conformité
  • Avec un TCO faible (coût total de possession), cela réduit la charge des coûts de sécurité et de conformité
  • Cela pose les bases d’une gestion robuste d’un environnement logiciel open source devenu plus complexe

Ce que disent les concurrents à propos des changements chez Bitnami

• Certains concurrents entretiennent le malentendu selon lequel Bitnami « supprime les images publiques gratuites et les charts Helm »
  • En réalité, les charts Helm restent publics sur GitHub sous licence Apache 2
  • Le cœur du changement concerne les artefacts OCI (images construites)
  • Les pipelines de build et de distribution à grande échelle, ainsi que l’exploitation des registres, ont un coût très élevé et ne peuvent pas être fournis à bas coût
  • Les sources des charts Helm (y compris les images Debian) restent accessibles gratuitement à tous
• Si une entreprise a besoin d’images OCI construites directement, elle doit être prise en charge via un abonnement BSI, ce qui constitue un moyen d’obtenir une meilleure sécurité et un usage stratégique de l’OSS

Modalités concrètes de la transition après le 28 août

• À partir du 28 août, le dépôt Bitnami commencera un nettoyage progressif des images, et l’ensemble des changements n’interviendra pas d’un seul coup
• La suppression et le déplacement des images se feront progressivement sur plusieurs semaines afin de réduire au minimum la confusion pour les utilisateurs
  • En raison du traitement de 84 To de contenu OCI, il est impossible de savoir précisément quelle image sera supprimée et quand
  • À partir du 28 août, pour les images nécessaires aux fonctions métier critiques, il faut préparer un registre alternatif
• Dans le nouveau registre Bitnami, les images Photon renforcées seront publiées sous le même nom que les anciennes images Debian
• Les utilisateurs existants comme les nouveaux utilisateurs pourront répondre aux dernières exigences de l’écosystème open source grâce aux images renforcées
• Des informations détaillées sur la transition sont disponibles dans la FAQ Bitnami

[jic5760]

Pour faire perdurer Bitnami au sein de la communauté, nous avons créé hier Bitmoa.
L’objectif est de remplacer les images Bitnami avec un minimum de changements (ENV, par exemple).

https://github.com/bitmoa/containers (build des images via GitHub Actions)
https://github.com/bitmoa/charts

[GN⁺]

Avis Hacker News

• Il est assez surprenant qu’ils envisagent de basculer vers un modèle commercial à la Oracle alors qu’ils ne font « que » empaqueter des logiciels publics sans vraiment y contribuer, même si ce n’est pas pour minimiser leur travail ; on peut se demander quelle part relève réellement du droit d’auteur, puisque dans la plupart des cas chaque paquet n’est qu’une recette d’assemblage de quelques lignes, et cela donne presque l’impression de vouloir revendiquer un copyright sur une ligne de commande du type make build ; de plus, si la distribution des binaires produits relève d’une licence open source, les utilisateurs doivent normalement avoir accès au code source, à la méthode de build et au droit de redistribution
  • Les Makefiles et autres éléments créés par Bitnami représentent tout de même un effort réel, et rendre divers logiciels utilisables via de simples variables d’environnement n’a rien de facile ; l’exemple ici vaut le détour, et pour une certaine catégorie d’utilisateurs une licence commerciale a aujourd’hui une vraie valeur
  • En réalité, la valeur la plus importante est peut-être surtout dans les charts Helm ; mais comme il existe déjà des alternatives sous forme d’images officielles, il n’y a pas vraiment de raison particulière d’utiliser les images Node ou Postgres de Bitnami, donc on peut se demander combien de gens utilisaient réellement les charts Helm de Bitnami
• Les hardened images proposées par Bitnami étaient un geste de goodwill et servaient à mettre le pied à l’étrier là où c’était vraiment utile ; mais elles n’arrivaient pas à rivaliser avec de meilleures options sur le marché ; ce passage à l’« abonnement » ne ressemble pas à une solution mais plutôt à une forme de vente forcée, un peu comme ce qu’a fait Terraform Cloud, et de ce côté-là la situation ne semble pas bonne non plus ; la contribution de Bitnami se limite en pratique à quelques options de configuration, ce qui correspond à peine à un niveau 2, voire 1, dans les capacités OperatorFramework lien de référence
  • Je trouve exagéré de parler de « vente forcée » alors que Bitnami fournissait cela gratuitement et arrête simplement ; les utilisateurs doivent chercher une alternative, certes, mais il y a déjà matière à être reconnaissant pour ce qui a été offert gratuitement jusque-là
  • Dire que c’est de la vente forcée parce qu’ils ne veulent plus donner gratuitement quelque chose qu’ils offraient avant, c’est une formule extrême ; au fond il reste surtout la frustration de devoir désormais le faire soi-même
  • Il semble y avoir une confusion sur ce qu’est Broadcom ; Broadcom n’est pas une entreprise intéressée par une « santé à long terme » ; quand elle rachète un produit, elle licencie 90 % du personnel puis augmente les coûts de licence et de support de 2 à 100 fois ; elle exploite le fait que les entreprises du Fortune 500 ne peuvent pas facilement se retirer, les enferme dans des contrats d’environ cinq ans et en extrait un maximum ; elle se soucie peu de la réaction du marché et, même en cas de contentieux, sa stratégie consiste à conserver malgré tout l’effet des hausses de prix
  • En 2025, pour une entreprise d’infrastructure, la stratégie qui consiste à gagner d’abord en popularité auprès des développeurs puis à transformer cela en chiffre d’affaires ne fonctionne plus ; il faut générer du revenu dès le départ, et au final le seul objectif est le marché entreprise ; tout le monde se bat pour occuper ce segment étroit
  • La valeur ajoutée qu’ils apportaient est très faible, mais le fait que certains utilisateurs souffrent déjà à l’idée de devoir remplacer même cela mérite réflexion
• Au final, cela tient aussi à la RSE (responsabilité sociétale des entreprises), et c’est également grâce à la RSE qu’une telle transition est possible ; la réglementation de l’EU Cyber Residence Act pourrait profondément modifier l’écosystème open source ; désormais, les entreprises qui fournissent commercialement des produits fondés sur l’open source devront respecter strictement des exigences de sécurité et de documentation ; les projets purement open source ne sont pas concernés, mais dès lors qu’il y a distribution payante, une charge juridique apparaît ; au bout du compte, vendre des cadres de conformité sous forme de service semble être une nouvelle opportunité
  • La RSE n’oblige pas nécessairement à ne proposer que des images de sécurité payantes ; s’ils le veulent, ils peuvent aussi continuer à en fournir gratuitement, ou ne rendre payant que l’usage commercial
  • Si l’on vend commercialement un service fondé sur de l’open source, le travail de conformité lié à la RSE est de toute façon indispensable ; au final, que ce soit open ou commercial, l’effort à fournir est le même
• Si vous avez besoin d’une alternative, l’équipe de Twistlock a lancé Minimus ; les images sont construites directement depuis les sources et fournies en continu avec presque aucune vulnérabilité ; il existe aussi un remplacement direct compatible avec Bitnami ; si vous avez des questions sur l’utilisation, les outils ou les cas clients, n’hésitez pas, et vous pouvez consulter ce post comparatif et explicatif
  • Le formulaire d’inscription de Minimus distingue « particulier » et « organisation », mais il est étrange que le nom de l’entreprise soit obligatoire ; on dirait surtout une logique marketing
  • Pour rendre plus claire la comparaison entre Minimus et Bitnami Secure Images évoquée sur le blog : les Bitnami Secure Images sont construites sur Photon, et lorsqu’une vulnérabilité ou une nouvelle version sort, elles sont automatiquement reconstruites, testées et déployées ; l’utilisateur n’a qu’à utiliser la dernière version, sans avoir à surveiller les CVE ni à faire des correctifs manuels
  • Le prix est le principal sujet ; j’ai déjà perdu tout intérêt pour Chainguard ou les Docker secure images après avoir entendu leurs tarifs ; il n’y a aucune information sur le prix de Minimus sur son site, ce qui fait soupçonner que ce sera probablement trop cher pour la plupart des usages
  • Je me demande si Minimus est un OS ; Bitnami, lui, reste un projet open source dont on peut encore construire les images directement depuis les sources
  • Ce serait bien que Minimus implémente directement un helper docker-credential, en s’inspirant de docker-credential-cgr de Chainguard, au lieu de simplement dire « Docker prend en charge un credential store, débrouillez-vous » référence
• Vu le coût de licence, à plus de 50 000 $ par an, je ne fais clairement pas partie de la cible
  • L’explication officielle affirme que « BSI démocratise la sécurité et la conformité open source », mais 50 000 $ n’ont rien de très « démocratique »
  • La terminologie est un peu confuse, mais en pratique ils sont en train de faire passer à un modèle payant diverses images auparavant gratuites ; on peut toujours récupérer les fichiers Docker et utiliser les images Docker Hub, mais la partie gratuite est désormais destinée au « développement » seulement, avec des restrictions pour la production, tandis que les vraies images « secure » sont construites sur Photon OS et passent par un processus de sécurité ; rien n’empêche cependant d’utiliser d’autres services
  • C’est la stratégie la plus simple pour monétiser une base d’utilisateurs existante en la laissant sans mises à jour, ce qui a quelque chose d’un peu absurde
• Il y a presque deux ans, dans l’entreprise, j’avais recommandé de quitter Bitnami, et le projet touche justement à sa fin maintenant, donc c’est satisfaisant de constater que c’était une bonne anticipation
• Avec les changements de licence chez VMware, il semble clair que Broadcom cherche à prendre la place d’Oracle, ce qui est regrettable à une époque où la concurrence s’intensifie
  • J’attends presque de voir comment Broadcom va monétiser l’écosystème Spring ; pratiquement toutes les grandes entreprises utilisent Spring, donc cela paraît inévitable à court terme
  • En réalité, Broadcom est surtout le nom repris par Avago Technologies après son acquisition en 2015-2016 ; les activités et la propriété intellectuelle du véritable Broadcom ont déjà été en grande partie revendues
  • Quand on réalise à quel point Broadcom peut être réellement « brutal », toute cette affaire peut presque sembler mineure ; malgré tout, à court terme, les utilisateurs peuvent même y trouver un avantage
  • Il est probable qu’une bonne partie des ingénieurs de Bitnami ne soit pas du tout d’accord avec ce genre de décision
  • Tant que Microsoft existe, Broadcom et Oracle se disputent surtout la deuxième place au classement du mal
• Les projets logiciels se composent soit de (1) code que l’on administre soi-même ou dont on paie la maintenance, soit de (2) code de second ordre qu’il faudra un jour remplacer par une version incompatible ; assembler uniquement du code de second ordre peut être un pari tout à fait rationnel, mais si les dépendances appartiennent à des tiers, il ne faut jamais s’attendre à ce qu’ils les maintiennent quasi indéfiniment ; la vraie gestion du risque consiste à partir du principe que le cycle de vie de votre projet sera plus court que celui de ses dépendances
• C’est regrettable que Broadcom ne sache même pas faire correctement le rembourrage mobile ; cela dit, ils auraient pu créer docker.io/bsi séparément et laisser /bitnami tel quel pour les anciennes versions : rien ne se serait cassé, et les utilisateurs auraient pu migrer à leur rythme, avec une explication naturelle de l’absence de mises à jour
  • Si Bitnami mettait fin aux mises à jour de sécurité gratuites, ils auraient dû laisser les utilisateurs accepter explicitement ce risque ; après un préavis suffisant, déplacer /bitnami vers /bitnamilegacy aurait aussi été une approche raisonnable
  • Le nom « bitnami » possède en lui-même une valeur de marque, donc continuer à l’utiliser pour vendre un nouveau service est un choix cohérent d’un point de vue business
  • Le problème de « rembourrage » chez Broadcom me fait penser au fait que l’interface de Rally semble elle aussi beaucoup trop datée
• Je n’ai jamais réussi à comprendre les conventions des images et paquets Bitnami ; à l’usage, c’était beaucoup trop complexe, avec des règles maison pénibles, plutôt qu’un paquet simple basé sur une image standard ; dès qu’on voulait modifier quelque chose, cela devenait un chaos total
  • Ils ont ignoré toutes les conventions habituelles pour empiler leurs propres scripts complexes, si bien qu’il faut lire la documentation de chaque image séparément pour pouvoir s’en servir ; cela ne correspond pas à la documentation officielle par défaut et c’était très frustrant
  • À une époque, j’utilisais les images Bitnami pour obtenir facilement des images de base rootless, car il était alors difficile de configurer proprement Postgres et d’autres logiciels en rootless dans les dépôts officiels ; mais selon l’image Bitnami, les UID ou les chemins de configuration changeaient, et il fallait toujours lire les Dockerfiles un par un
  • Bitnami était à l’origine populaire pour faire tourner Wordpress sous Windows ; ils rendaient cela directement utilisable sur Windows Server, ce qui était utile à l’époque ; aujourd’hui, on se ferait peut-être renvoyer pour faire ce genre de choix, mais à ce moment-là la démocratisation de Linux était plus lente, donc ce service avait sa raison d’être
  • Je me demande s’il existe des ressources utiles pour mieux comprendre ce type de conventions de packaging ; j’ai l’impression que la pratique la plus courante consiste plutôt à partir des images officielles du projet, à les personnaliser chacun de son côté, puis à construire ses propres images