Änderungen am Bitnami-Image-Katalog – Zeit zu handeln!

Bitnami was ist das?

Bitnami ist ein Anbieter von vorgefertigten Software-Paketen, die beliebte Anwendungen wie WordPress, Joomla oder GitLab enthalten und sich leicht auf Servern installieren lassen. Bitnami fing 2007 mit dem Ziel an, Open-Source-Software als Enterprise Lösung bereit zu stellen. Nach der VMware Übernahme 2019 wurde das Ziel weiterverfolgt, die Kataloge aktiv gepflegt und sichergestellt, dass sie regelmäßig aktualisiert und gewartet werden. Die bereitgestellten Pakete sind als sogenannte „Stacks“ erhältlich, die alle notwendigen Abhängigkeiten (z.B. Datenbanken, Webserver) enthalten. Bitnami unterstützt verschiedene Plattformen, darunter lokale Rechner, virtuelle Maschinen, Container (wie Docker) und Cloud-Dienste (z.B. AWS, Azure). Ziel ist es, die Einrichtung und Verwaltung von Anwendungen zu vereinfachen und zu standardisieren.

Bitnami stellt um – das sollten Sie als Endnutzer wissen: (TL; DR)

Zum 29. September 2025 werden bisherige Bitnami-Images nicht mehr unter dem bekannten Image Repository docker.io/bitnami verfügbar sein, sondern in das neue Repository docker.io/bitnamilegacy verschoben und erhalten keine Updates mehr.

Die kommerzielle Lösung ist jetzt unter dem Namen „Bitnami Secure Images (BSI)“ zu finden. Diese Images sind sicherheitsgehärtet und werden von Broadcom weiterhin gepflegt. Diese Images werden zusätzlich mit SOMs Informationen und VEX-Daten (Vulnerability Exploitability) gebaut. Darüber hinaus bleibt unter der kommerziellen Lösung auch der Support für die entsprechenden Bitnami Helm Charts. 

Auswirkungen

Nach dem Stichtag stehen Bitnami Images eingeschränkt zur Verfügung, die laufenden Applikationen können nicht mehr aktualisiert werden. Das bisherige Images Repository docker.io/bitnami wird abgeschaltet. Die bisherigen Images werden in einem Legacy Repository verfügbar sein docker.io/bitnamilegacy, allerdings werden diese nicht mehr mit Updates versorgt. Dazu wird es ein kostenpflichtiges Repository docker.io/bitnamisecure geben.

Wenn man also untätig bleibt und die Image-Repositories in seinen Deployments nicht auf eine der beiden neuen Image-Repositories ändert, geht ein hohes Risiko ein, dass es zu ImagePullErrors kommen wird, wenn die Applikation neustartet und Images neu gepullt werden müssen.

Damit dies vor allem nicht in einer produktiven Umgebung passiert, muss hier gehandelt werden.

Optionen:

In der aktuellen Diskussion innerhalb der Community zeigen sich unterschiedliche Perspektiven: Die einen verfolgen weiterhin den bewährten Open-Source-Gedanken und setzen auf freie Verfügbarkeit und gemeinschaftliche Weiterentwicklung. Die anderen schließen einen kostenpflichtigen Service nicht aus – vorausgesetzt, dieser Mehrwert steht in einem angemessenen Verhältnis.

Aus unseren Erfahrungen und auf Basis der uns vorliegenden Informationen sehen wir die folgenden Optionen:

1. Bitnami Secure Image als kommerzielle Lösung. Wechsel zur kostenpflichtigen Bitnami-Lösung über Arrow
2. Kommerzielle Variante von BSI: Tanzu Application Catalog => TAC ist Teil des Tanzu Portfolios von Broadcom. Lizenzen können durch Partner beschaffen werden.
3. Wechsel zu einem anderen Anbieter gehärteter Images (z. B. Chainguard–kostenpflichtig).
4. Auf Open Source Alternativen umstellen (mit Aufwand verbunden)

Optionen im Detail

Option 1 

Die Option 1 bietet eine kommerzielle Lösung über BSI, bei der ein Paket von mindestens zehn Artefakten erworben werden kann. Für Organisationen, die regelmäßig Bitnami-Images nutzen und weiterhin auf deren Stabilität und Sicherheit angewiesen sind, kann dies eine sinnvolle Investition darstellen.

Lass uns aber im Detail schauen, was es genau bedeutet:

Kunden mit einer aktiven BSI-Subscription erhalten Zugriff auf das vollständige Debian-Repository – allerdings ohne gehärtete Images. Der Zugriff auf dieses Repository ist Teil der Subscription und kommt zusammen mit den ersten 10 lizenzierten Artekfakten. Diese Artefakte basieren im Gegenteil auf Photon OS, sind geprüft, gehärtet, produktionsreif und werden regelmäßig vom Hersteller gewartet.

Wichtige Anmerkung!

Bitnami Secure Image wird in Paketen zu je 10 Artefakten verkauft. Das bedeutet, dass Sie beim Lizensieren von 12 Artefakten das Paket mit 20 erwerben müssen.

Klarstellung: Was genau ist ein Artefakt?

Artefakte sind grundsätzlich Bausteine, um Anwendungen zu entwickeln, zu testen und bereitzustellen. Hier eine Zusammenfassung der wichtigsten Punkte, die zu berücksichtigen sind, um eine Vorstellung davon zu bekommen, wie viele Artefakte benötigt werden. 

• Ein Image ist ein Artefakt
• Ein Helm Chart ist ein Artefakt
• Ein Helm Chart, der verschiedenen Images (z.B. als Subcharts) enthält, ist ein Artefakt
• Zwei Images, die in Produktion laufen, unter zwei unterschiedlichen Tags, sind zwei Artefakte

Option 2

Bei Option 2 handelt es sich ebenfalls um eine kommerzielle Variante, die direkt von Broadcom angeboten wird. Der Tanzu Application Catalog ist ein rebrand von Bitnami Secure Images. Was ist der Unterschied? Beim TAC erhält der Kunde keinen Zugriff auf den Debian Repository, kann aber, nach der Mindestanzahl von 10 Artefakten, einzelne weitere lizenzieren. Das bietet etwas mehr Flexibilität und setzt den Fokus auf einen security-first Ansatz, da nur gehärtete Images im Catalog zur Verfügung stehen.

Kann ich also mit Tanzu Application Catalog 12 Artefakte lizenzieren, ohne ein Paket von 20 erwerben zu müssen? Die Antwort lautet – ja!

Warum bekommt man keinen Zugriff auf das Debian Repository wie bei BSI? Die Antwort lautet – security-first Ansatz! Broadcom setzt zum einen den Fokus auf die Weiterentwicklung und Optimierung des Photon Betriebssystems und zum anderen garantiert near-zero CVE und gehärtete Images, die regelmäßig gepflegt und aktualisiert werden. Besonders für Kunden, die hohe Sicherheitsanforderungen erfüllen müssen, ist das sicherlich zum Vorteil.

Der letzte Punkt, auf den wir kurz eingehen wollen hier hat mit dem Migrationsprozess zu tun. Das ist sowohl bei BSI als auch bei TAC sehr gering.  Der große Vorteil von Option 1 und 2 ist, man spart sich den ganzen Migrationsstress. Praktisch wären folgende Schritte erforderlich:

1. Secret erstellen (imagePullSecret)

kubectl create secret docker-registry regcred \
  --docker-server=registry.vmware.com \
  --docker-username=<dein Benutzername> \
  --docker-password=<dein Zugriffstoken> \
  --docker-email=<deine E-Mail>

kubectl create secret docker-registry regcred \
  --docker-server=registry.vmware.com \
  --docker-username=<dein Benutzername> \
  --docker-password=<dein Zugriffstoken> \
  --docker-email=<deine E-Mail>

2. PostgreSQL mit Helm und Secure Image deployen

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

helm install my-postgres bitnami/postgresql \
  --set image.registry=registry.vmware.com \
  --set image.repository=bitnami/postgresql \
  --set image.tag=15.4.0-secure \
  --set image.pullSecrets[0].name=regcred \
  --set auth.postgresPassword=securePass123 \
  --set primary.persistence.size=10Gi

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

helm install my-postgres bitnami/postgresql \
  --set image.registry=registry.vmware.com \
  --set image.repository=bitnami/postgresql \
  --set image.tag=15.4.0-secure \
  --set image.pullSecrets[0].name=regcred \
  --set auth.postgresPassword=securePass123 \
  --set primary.persistence.size=10Gi

Option 3 

Eine Frage, die wir oft gestellt bekommen haben ist: Gibt’s sonst kommerzielle Lösungen und wenn ja, woran unterscheiden sie sich zu Bitnami/TAC? Wir haben hier als Beispiel Chainguard genommen. Chainguard tritt als schlanke Alternative auf und liefert minimale, gehärtete Images auf Basis von Wolfi, einer eigenen Linux-Distribution. Chainguard, genauso wie BSI/TAC, unterstützt FIPS, STIG und FedRAMP, mit einem stärkeren Fokus auf kritische Infrastrukturen. Allerdings ersetzt Chainguard Bitnami nicht vollständig: Helm-Charts müssen separat gepflegt oder selbst erstellt werden. Darüber hinaus ergibt sich bei den wirtschaftlichen Rahmenbedingungen kein klarer Vorteil von Chainguard. Ob Chainguard eine bessere Alternative sein könnte, müsste letztendlich tiefer evaluiert werden und hängt oft von Kundenanforderungen an.

Option 4

Open-Source-Alternativen sind eine kostenfreie Lösung. Allerdings sollte deren Einsatz sorgfältig geprüft werden, da sie zu einem erhöhten Aufwand und Sicherheitsrisiken führen können.

Ein Wechsel zu Open-Source Alternativen braucht auf jeden Fall einen individuellen Migrationsplan pro Applikation. Es gibt manche Applikationen, bei denen wird ein Wechsel schwieriger als bei anderen. In jedem Fall sollte man sich überlegen, dass die Charts stark variieren können und es zu einem erhöhten Aufwand bei der Wartbarkeit kommen kann. Vor allem wenn in den Charts Dependencies aus weiteren Charts benutzt werden und die Images ggf. noch in unterschiedlichen Image Registries abgelegt sind. Nicht außer Betracht geraten darf die Sicherheit und man muss im Hinterkopf behalten, dass nicht jedes Image gehärtet ist. Dies hat zur Folge, dass man sich hardening Pipelines selbst bauen muss. Ebenfalls muss sich um CVE Scanning und einbinden von zusätzlichen SBOMs (Software Bill of Materials) und VEX (Vulnerability Exploitability Exchange) selbst managen. Man benötigt mit den Alternativen also ein eigenes Sicherheitskonzept. Dies ist durch aus machbar, wenn es ein entsprechendes Team dafür gibt oder man dies aufbaut.
Einen Punkt darf man auch nicht ignorieren: was passiert, wenn eines der Open-Source Alternativen ebenfalls in den kommerziellen Bereich einsteigt oder die Community das Projekt aufgibt? Dafür braucht es eine Risikoanalyse, bei der solche Punkte betrachtet werden sollten.

Welche Maßnahmen sind erforderlich, um das Konzept am Beispiel einer Harbor Registry mit externer PostgreSQL umzusetzen? 

1. Im ersten Schritt benötigt es eine Open-Source Variante für die Bitnami PostgreSQL. Dafür kann man den “cloudnative-postgres-operator“ benutzen. Dazu installiert man den pg-Operator in

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

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

2. Nachdem der Operator installiert wurde, kann mit dem Deployment einer PostgreSQL-Instanz via CRD fortgefahren werden. Dabei muss darauf geachtet werden, dass alle Datenbanken, User und Roles passend wie in der Bitnami PostgreSQL angelegt werden. Sonst kann man, den pq dump unter Umständen nicht richtig übertragen.

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

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

3. Je nach Vorgehen muss die bestehende Harbor herunter skaliert werden, um eine Daten-Konsistenz zu bewahren. Und ein Dump muss von der bitnami Instanz auf die neue Instanz übertragen werden.

4. Die Alternative zu einer Bitnami Harbor ist goHarbor. Diese kann ebenfalls mit Helm installiert werden.

helm repo add harbor https://helm.goharbor.io
helm fetch harbor/harbor --untar

helm repo add harbor https://helm.goharbor.io
helm fetch harbor/harbor --untar

5. Nachdem die grundsätzlichen Konfigurationen in den Values geändert wurden, braucht es nun noch einige, um die Migration von Bitnami Harbor zur goHarbor durchzuführen. Ein Beispiel, um die PVCs weiter zu nutzen wäre es in den goHarbor Values, diese als “existingClaims” anzugeben. Zusätzlich braucht es allerdings auch noch einen InitContainer oder einen manuellen Eingriff, dass die Ordner/Files in dem z.B.  Registry PVC von 1001 auf 1000 User und Group ändert. Bitnami verwendet nämlich den User 1001 und goHarbor den User 1000.

persistence:
         enabled: true
         persistentVolumeClaim:
           registry:
             existingClaim: "harbor-registry"

persistence:
         enabled: true
         persistentVolumeClaim:
           registry:
             existingClaim: "harbor-registry"

6. Installation der goHarbor, überprüfen der Konfiguration, Testen ob Images gepush und gepullt werden können. Wenn alles stimmig ist, können die Bitnami-Instanzen abgebaut werden.

In dem Fall von Harbor muss auf die Datenbank bzw. deren User und Roles geachtet werden und der User für die Files auf den PVC sind unterschiedlich. An diesem Beispiel wird deutlich, dass eine Migration gut geplant sein muss, denn es kann in anderen Fällen auch mehr Aufwände geben. Denn es kann vorkommen, dass sich das Filesystem von einer Bitnami-App zu einer anderen deutlich unterscheidet.

Fazit

Welche Lösung in Ihrem spezifischen Szenario infrage kommt, lässt sich nicht pauschal festlegen. Die Auswahl hängt wesentlich von individuellen technischen Gegebenheiten und lizenzrechtlichen Vorgaben ab. Wir von Evoila helfen Ihnen, ihre Bitnami-Nutzung systematisch zu erfassen und entwickeln daraus eine gemeinsame Strategie, damit Ihr operativer Betrieb nicht ins Stocken gerät.

Offizielle Nachricht: https://github.com/bitnami/containers/issues/83267