Helm-Charts in Gefahr? Bitnami Images werden kostenpflichtig

Bitnami ist für viele Kubernetes- und Cloud-Teams ein vertrauter Name. Die vorgefertigten Container-Images und Helm-Charts für Anwendungen wie PostgreSQL, Redis oder Keycloak haben es einfach gemacht, Open-Source-Software schnell und zuverlässig in Kubernetes bereitzustellen.

Wer eine neue Datenbank oder einen Cache brauchte, konnte bisher darauf vertrauen, dass Bitnami ein getestetes Image und gleich das passende Helm-Chart mitliefert. Doch diese Selbstverständlichkeit steht nun vor einem großen Umbruch: Broadcom, seit der VMware-Übernahme Eigentümer von Bitnami, stellt das bisherige kostenlose Image-Angebot in weiten Teilen ein.

Was ändert sich konkret?

Ab dem 28. August 2025 werden ältere und versionierte Bitnami-Images nicht mehr unter der bekannten Registry docker.io/bitnami verfügbar sein. Stattdessen wandern sie in ein „Legacy Repository“, das keine Sicherheitsupdates mehr erhält.

Parallel dazu führt Broadcom die Bitnami Secure Images ein: kommerzielle, sicherheitsgehärtete Container-Images, die in einem reproduzierbaren Build-Prozess erstellt werden und mit zusätzlichen Informationen wie SBOMs (Software Bill of Materials) sowie VEX-Daten (Vulnerability Exploitability Exchange) ausgeliefert werden. Diese Images werden langfristig in LTS-Branches gepflegt – allerdings nur im Rahmen eines kostenpflichtigen Abonnements.

Die Helm-Charts selbst bleiben zwar Open Source und unter Apache-2-Lizenz auf GitHub verfügbar, doch sie referenzieren standardmäßig auf Images, die nach dem Stichtag ohne Subscription nicht mehr zugänglich sein könnten. Wer also nach dem 28. August ein helm upgrade durchführt, riskiert fehlschlagende Deployments.

Warum macht Bitnami das?

Broadcom verfolgt seit der Übernahme von VMware eine klar auf Enterprise-Kunden ausgerichtete Strategie. Das Ziel: Kunden in regulierten oder sicherheitskritischen Umgebungen ein vollständig kontrolliertes und überprüftes Container-Ökosystem zu bieten.

Bitnami Secure Images (BSI) sollen dabei nicht nur Sicherheit und Compliance garantieren, sondern auch eine stabile Lieferkette mit nachvollziehbaren Builds schaffen. Für Unternehmen, die auf Zertifizierungen und Audits angewiesen sind, ist das attraktiv. Für kleinere Teams oder Open-Source-Projekte hingegen kann die neue Kostenstruktur eine echte Hürde darstellen.

Auswirkungen in der Praxis

Die Änderungen treffen nicht nur große Plattform-Teams, sondern auch viele kleinere Projekte:

• Helm-Charts könnten brechen, wenn die referenzierten Images nicht mehr verfügbar sind.
• CI/CD-Pipelines riskieren Build-Fehler, wenn docker pull nicht mehr funktioniert.
• Sicherheitslücken bleiben offen, wenn Legacy-Images ohne Updates im Einsatz bleiben.

Gerade in produktiven Umgebungen kann das zu Ausfällen oder Compliance-Problemen führen.

Handlungsoptionen für Teams

Kurzfristig lässt sich der Betrieb sichern, indem man Helm-Charts so anpasst, dass sie auf das Legacy-Repository zeigen oder benötigte Images in eine eigene Registry spiegelt. Letzteres sorgt für Stabilität, löst aber nicht das Problem fehlender Sicherheitsupdates.

Langfristig gibt es drei Ansätze:

1. Bitnami Secure Images abonnieren
   Wer Wert auf Support, Sicherheit und LTS legt, kann die kommerzielle Lösung in Betracht ziehen. Der manuelle Aufwand zur Härtung von Images sollte hierbei nicht unterschätzt werden!
2. Eigene Images bauen
   Dafür können die Open-Source-Helm-Charts geforkt und auf alternative Basis-Images (z. B. Docker Official Images, Chainguard oder Distroless) umgestellt werden. Hierbei ist allerdings zu beachten, dass die Bitnami-Images meisst mehr als nur den reinen Service implementiert hatten. So wurde beispielsweise bei dem PostgreSQL Image auch das entsprechende Seeding von Datenbanken und Nutzern im EntryPoint des Image mit durchgeführt.
3. Auf Alternativen aus der Community oder vom Hersteller setzen
   Viele Anwendungen werden direkt vom Upstream-Projekt als Container-Image gepflegt. Häufig gibt es auch OEM-Helm-Charts oder dedizierte Kubernetes-Operatoren. Wie beispielsweise folgende Projekte beweisen:
   • Für PostgreSQL bietet sich etwa der cloudnative-pg Operator an, ein CNCF-Projekt, das Installation, Updates, Hochverfügbarkeit und Backups automatisiert.
   • Keycloak lässt sich ebenfalls mit einem Operatoren von der Community betreiben.
   • Redis lässt sich mit Operatoren wie dem von Spot.io oder dem Helm-Chart des Herstellers betreiben.

Der Einsatz von Operatoren hat den Vorteil, dass viele Betriebsaufgaben direkt automatisiert werden und sich die Integration in Kubernetes-Workflows verbessert. Trotzdem ist es auch hier Notwendig eine Auge auf die Härtung der Images zu legen und diese – bei Bedarf – selbstständig nachzubessern.

Praktisches Beispiel: PostgreSQL-Deployment anpassen

Damit der Wechsel reibungslos gelingt, lohnt sich ein Blick in die values.yaml des Bitnami PostgreSQL Helm-Charts. Hier lassen sich die Image-Quelle und der Tag überschreiben.

1. Kurzfristig: Nutzung des Legacy-Repository

image:
  registry: docker.io
  repository: bitnamilegacy/postgresql
  tag: 15.4.0

Das funktioniert nur so lange, wie die benötigte Version im Legacy-Repo liegt – Updates gibt es dort nicht mehr.

2. Etwas robuster: Spiegelung in eine eigene Registry

# Image aus dem Legacy-Repo ziehen
docker pull docker.io/bitnamilegacy/postgresql:15.4.0

# In eigene Registry pushen
docker tag docker.io/bitnamilegacy/postgresql:15.4.0 registry.example.com/postgresql:15.4.0
docker push registry.example.com/postgresql:15.4.0

Im Helm-Chart verweist du dann auf deine Registry:

image:
  registry: registry.example.com
  repository: postgresql
  tag: 15.4.0

So bist du nicht mehr von Änderungen bei Bitnami abhängig – Updates musst du allerdings selbst einspielen.

3. Alternative: Einsatz des cloudnative-pg Operators

Installation des Operators:

helm repo add cnpg https://cloudnative-pg.github.io/charts
helm install cnpg cnpg/cloudnative-pg

Deployment einer PostgreSQL-Instanz via CRD:

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: my-postgres
spec:
  instances: 3
  imageName: ghcr.io/cloudnative-pg/postgresql:15.4
  storage:
    size: 10Gi

Der Operator kümmert sich anschließend um Hochverfügbarkeit, Backups und Updates – ohne dass du manuell ein Helm-Chart anpassen musst.

Fazit

Die verbleibende Zeit bis zum 28. August sollte genutzt werden, um Klarheit zu schaffen:
Welche Bitnami-Images sind im Einsatz? Sind die genutzten Versionen nach dem Stichtag noch zugänglich? Und welche Migrationsstrategie passt zur eigenen Organisation – Secure Images, Eigenbau oder ein Umstieg auf OEM-Charts bzw. Operatoren?

Je eher diese Fragen beantwortet werden, desto reibungsloser kann der Wechsel erfolgen.

Die Umstellung bei Bitnami ist ein deutliches Beispiel dafür, wie schnell sich die Rahmenbedingungen im Open-Source-Ökosystem ändern können – besonders dann, wenn beliebte Projekte in den Besitz großer Konzerne gelangen. Für Betreiber von Kubernetes-Workloads bedeutet das: Nicht allein auf die Bequemlichkeit bestehender Lösungen verlassen, sondern frühzeitig Alternativen evaluieren.

Wer jetzt handelt, kann Ausfälle vermeiden und seine Plattform langfristig unabhängiger und resilienter aufstellen.