Images Bitnami : ce qui va changer fin août et comment anticiper la transition

Bitnami vient de lancer une bombe dans la communauté DevOps : dès le 28 août 2025, la génération d’images Debian gratuites versionnées s’arrête. Ces images, aujourd’hui incontournables dans de nombreux pipelines CI/CD, migreront vers un dépôt Legacy, sans mises à jour ni correctifs de sécurité. Pour accéder aux images durcies, sécurisées et avec support long terme, il faudra désormais passer par l’offre payante Bitnami Secure Images. Ce changement est majeur, mais pas isolé. Après Red Hat et Docker, Bitnami confirme une tendance lourde du marché : sécuriser la supply chain logicielle, mais en passant par la case monétisation. Voici ce que cela implique pour vous, et surtout comment anticiper efficacement. Place à la magie.

Découvrir nos services DevOps

À partir du 28 août 2025, toutes les images Debian actuellement proposées gratuitement par Bitnami sous tags spécifiques (ex : docker.io/bitnami/postgresql:15.2.0) migreront vers un dépôt « Legacy » (docker.io/bitnamilegacy).

Ces images Legacy ne recevront plus aucune mise à jour, exposant potentiellement vos environnements aux nouvelles vulnérabilités (CVE). Par ailleurs, Bitnami conservera seulement quelques images gratuites avec le tag « latest », destinées uniquement au développement dans le dépôt docker.io/bitnamisecure.

Ce changement majeur touche directement votre CI/CD, vos Helm charts et vos Kubernetes manifests. Concrètement, dès le 28 août :

• Les tags spécifiques ne seront plus accessibles depuis le dépôt public.
• Vos pipelines risquent de se briser en raison du manque d’accès aux images versionnées
• L’usage prolongé des images Legacy augmentera considérablement le risque de sécurité, ces dernières ne recevant plus aucun correctif CVE.
  

Sans une anticipation technique précise, vous risquez des interruptions de service critiques et des problèmes de conformité.

Voici un plan d’action technique précis, issu directement de la documentation GitHub officielle de Bitnami :

1. Procédez à un audit technique des références d’images

Commencez par analyser vos pipelines CI/CD, Helm charts et manifests Kubernetes afin d’identifier précisément toutes les images référencées sous docker.io/bitnami/* avec des tags spécifiques.

2. Choisissez votre stratégie de migration

Trois stratégies possibles s’offrent à vous :

• Solution temporaire : basculez vos références vers le dépôt Legacy en modifiant docker.io/bitnami/* vers docker.io/bitnamilegacy/*.
  Un exemple de commande Helm :

helm upgrade myapp oci://registry-1.docker.io/bitnamicharts/<CHART> \
  --version <VERSION> \
  --set image.repository=bitnamilegacy/<app> \
  --set global.security.allowInsecureImages=true

• Solution durable : une migration directe vers les nouvelles images sécurisées, accessibles via docker.io/bitnamisecure, répondant aux exigences élevées en matière de sécurité et de conformité (SLSA, SBOM, VEX, LTS).
• Alternative durable et gratuite (pour les plus vaillants) : créez vos propres images à partir des sources open source disponibles publiquement (par exemple les sources Bitnami sous licence Apache 2). Cette voie vous garantit une autonomie complète sur vos builds et une intégration rapide des correctifs sécurité. En contrepartie, cette solution exige des compétences DevOps solides, une expertise en sécurité applicative et une infrastructure adaptée pour automatiser vos processus et maintenir un registre privé robuste.

Contacter un expert DevOps

3. Mise à jour et validation technique

Mettez à jour précisément vos fichiers Dockerfile, deployment.yaml, et Helm (values.yaml).

Effectuez impérativement des tests approfondis en environnement de staging :

• Validez le téléchargement correct des nouvelles images.
• Analysez les nouvelles images avec Trivy ou Grype pour vérifier l’absence de vulnérabilités critiques

4. Mise en production et documentation

Déployez avant la date limite du 28 août. 

Documentez minutieusement chaque changement et prévoyez une procédure de fallback vers le dépôt Legacy pour toute urgence.

Pour aller plus loin, appuyez-vous également sur des ressources fiables : documentation Docker officielle, documentation Helm et page officielle Bitnami Secure Images pour comprendre les offres et pratiques à jour.

Cette décision de Bitnami s’inscrit dans une dynamique déjà observée avec Red Hat et Docker. Voici quelques conseils pour vous préparer aux futures évolutions du marché.

Prévoyez désormais un budget pour l’accès aux images sécurisées

Analysez soigneusement les coûts de souscription par rapport à une gestion interne.

Réduisez la dépendance aux registres externes

Envisagez la création d’un registry privé en utilisant les sources ouvertes Apache 2 de Bitnami.

Mettez en place une stratégie interne DevSecOps solide

Préférez des bases distroless, automatisez le durcissement des images, et intégrez systématiquement SBOM et outils de conformité à votre chaîne CI/CD.

Utilisez un cache interne pour vos images Docker et vos charts Helm

Cela vous permet de conserver une copie locale des images déjà utilisées. Ainsi, si une version disparaît du dépôt public, vos déploiements ne sont pas impactés et vous évitez de casser vos déploiements en production. Voici à quoi ça pourrait ressembler :

| Kubernetes | ------> | Registry interne (par exemple Jfrog, AWS ECR, etc...) | ------> | Image Bitnami |

Attention, cette approche n’est pas magique : seules les images que vous avez déjà utilisées et mises en cache resteront accessibles. Par exemple, si vous utilisiez la version 1.1.0 et que la dernière version publique est 1.5.0, vous ne pourrez pas récupérer la 1.3.0 si elle n’a jamais été stockée dans votre cache.

À court terme, il est impératif d’appliquer des correctifs rapides pour éviter les ruptures et vulnérabilités immédiates liées à la migration Bitnami. À moyen et long terme, cette situation vous invite à repenser profondément votre stratégie CI/CD. La gestion proactive de vos dépendances et la mise en place d’une supply chain logicielle robuste et maîtrisée sont des priorités. Si besoin, nos experts DevOps peuvent vous accompagner dans cette transition.

Méfait accompli.