Löschung von docker.io/Bitnami

 (community.broadcom.com)
2 Punkte von GN⁺ 2025-08-30 | 2 Kommentare | Auf WhatsApp teilen
  • Das Bitnami-Team hat den Termin für die Löschung des öffentlichen Katalogs docker.io/bitnami auf den 29. September verschoben.
  • Um den Nutzern die Umstellung vor der Löschung zu erleichtern, sind mehrere Brownouts (vorübergehende Sperrung einiger Images) geplant.
  • Künftig werden die Container-Images und Helm-Charts von Bitnami zu Bitnami Secure Images (BSI) mit starken Sicherheitsfunktionen oder zur Bitnami Legacy Registry verschoben.
  • BSI-Images sind für Entwicklung und Tests kostenlos verfügbar, für den vollständigen Katalog und Long-Term-Support ist jedoch ein kostenpflichtiges Abonnement erforderlich.
  • Um auf Sicherheits- und regulatorische Veränderungen in der Open-Source-Lieferkette zu reagieren, ist ein Wechsel gegenüber dem bisherigen Modell notwendig geworden.

Zeitplan für die Entfernung des öffentlichen Bitnami-Katalogs auf docker.io und Hinweise zur Umstellung

Update

  • Das Bitnami-Team hat nach Feedback aus der Community und einer Folgenabschätzung den Zeitpunkt für die Löschung des öffentlichen Katalogs docker.io/bitnami auf den 29. September 2024 verschoben.
  • Vor der Entfernung der Registry sind drei Brownouts (24-stündige vorübergehende Sperrung bestimmter Container-Images) geplant, damit Nutzer die Änderung rechtzeitig bemerken.
      1. August 08:00 UTC ~ 29. August 08:00 UTC
      1. September 08:00 UTC ~ 3. September 08:00 UTC
      1. September 08:00 UTC ~ 18. September 08:00 UTC
  • Welche Images von den einzelnen Brownouts betroffen sind, wird jeweils am selben Tag angekündigt.
  • Ab dem 28. August werden Bitnami-Container-Images und Helm-Charts nicht mehr in einem neuen Format (OCI) über Docker Hub verteilt.
  • Der Quellcode der Container und Helm-Charts wird weiterhin unter der Apache-2.0-Lizenz auf GitHub bereitgestellt.

Was sich ändert

  • Ab dem 28. August verschiebt Bitnami die bestehende OCI-Registry (Charts und Images) zu Bitnami Legacy und stellt danach auf neue, sicherheitsgehärtete Images um.

  • Wer aktuelle Images nutzt, muss in automatisierten Pipelines, internen Mirrors und Kubernetes-Clustern die Image-Pull-Pfade auf den neuen Ort umstellen.

  • Nutzer haben folgende Optionen:

    1. Wechsel zu Bitnami Secure Images (BSI)
    2. Wechsel zur Bitnami Legacy Registry (vorübergehend)

  • Für dauerhaften Systembetrieb und den Erhalt der Funktionalität wird der Wechsel zu Bitnami Secure Images (BSI) empfohlen.

  • Mit BSI verbessern gehärtete Images die Reaktionsfähigkeit in Bezug auf Sicherheit und Compliance.

Wechsel zu Bitnami Secure Images (BSI)

  • Einige BSI-Images sind für Entwicklung und Tests kostenlos verfügbar, aber der vollständige Katalog, stabile Tags und Long-Term-Support-Versionen sind nur mit kostenpflichtigem Abonnement verfügbar.
  • BSI-Abonnenten erhalten auch künftig den vollständigen Katalog Debian-basierter Bitnami-Images sowie Updates.
  • Es wird empfohlen, auf stärker gehärtete Photon-Linux-basierte Images upzugraden und umzusteigen.
    • Sie sind mit bestehenden Debian-Images kompatibel, und Helm-Charts können unverändert weiterverwendet werden.
  • Wichtige Vorteile der Photon-basierten Images:
    • Deutlich weniger CVEs (in manchen Fällen von 100+ auf 0)
    • Unterstützung für VEX-Diagnosen und Anbindung von KEV-/EPSS-Scores für einfacheres Schwachstellenmanagement
    • Self-Service-UI/API mit starken Reporting- und Metadatenfunktionen
    • Unterstützung fortschrittlicher Helm-Charts wie distroless-Charts, die die Angriffsfläche um 83 % reduzieren
    • Anpassung von Build-Images in einer Softwarefabrik mit SLSA-3-Konformität (Supply-Chain-Sicherheitsstandard)
    • Bereitstellung einer kundenspezifischen privaten Security-OCI-Registry (anders als Docker Hub ohne Public-/Rate-Limit-Probleme)
    • Nutzung von mehr als 90 VM-Images im OVA-Format
    • Enterprise-Support für Packaging und Installation

Wechsel zur Bitnami Legacy Registry

  • Als Übergangslösung wird bestehenden Bitnami-Nutzern die Bitnami Legacy Registry bereitgestellt.
    • Es handelt sich um Images in einem nicht unterstützten Archivformat (z. B. ohne Sicherheits-Patches).
    • Es gibt keinen Plan für eine langfristige Bereitstellung: sich ansammelnde Schwachstellen und Alterung sind daher schnell zu erwarten.
    • Wer sie vorübergehend nutzt, sollte benötigte Images in eine eigene Registry kopieren.
    • Grundsätzlich ist ein schneller Wechsel auf das neue sicherheitsgehärtete System (BSI) erforderlich.

Warum ein Wechsel bei Open-Source-Supply-Chain-Sicherheit und Compliance nötig ist

  • Ein wesentlicher Hintergrund ist der jüngste Wandel im Open-Source-Umfeld sowie der starke Anstieg bösartiger Pakete (laut Sonatype von 2019 bis 2023 mehr als 245.000 Fälle).
    • Das entspricht etwa dem Doppelten aller vorherigen Zeiträume zusammen.
  • Mit dem Wachstum des AI-/Modell-Ökosystems nimmt auch die Nutzung von Open Source stark zu → Angriffsfläche und Risiken wachsen ebenfalls.
  • Durch Regulierungen wie den Cyber Resilience Act (EU) entsteht eine Nachweispflicht für Herkunft und Integrität von Open-Source-Software.
  • Mit der Einführung von Bitnami Secure Images bietet Bitnami Organisationen eine Umgebung, in der sich Supply-Chain-Sicherheit und Compliance leichter umsetzen lassen.
    • Niedrigere TCO (Total Cost of Ownership) zur Entlastung bei Sicherheits- und Regulierungskosten
    • Eine Grundlage, um das komplexer gewordene Open-Source-Software-Umfeld robust zu verwalten

Behauptungen von Wettbewerbern zu den Bitnami-Änderungen

  • Einige Wettbewerber erwecken fälschlich den Eindruck, Bitnami würde "kostenlose öffentliche Images und Helm-Charts abschaffen".
    • Tatsächlich bleiben Helm-Charts weiterhin unter der Apache-2-Lizenz auf GitHub öffentlich verfügbar.
    • Der Kern der Änderung betrifft OCI-Artefakte, also die gebauten Images.
    • Große Build- und Distributionspipelines sowie der Betrieb von Registries verursachen sehr hohe Kosten und lassen sich nicht zu niedrigen Kosten bereitstellen.
    • Auf Helm-Chart-Quellen (einschließlich Debian-Images) kann weiterhin jeder kostenlos zugreifen.
  • Unternehmen, die OCI-Build-Images direkt benötigen, müssen über ein BSI-Abonnement Unterstützung beziehen; dies dient der Verbesserung der Sicherheit und einer strategischen OSS-Nutzung.

Konkrete Umstellung ab dem 28. August

  • Ab dem 28. August beginnt das Bitnami-Repo mit einer schrittweisen Bereinigung der Images, die Umstellung erfolgt also nicht auf einmal.
  • Über mehrere Wochen hinweg werden Images nach und nach gelöscht oder verschoben → dies soll Verwirrung bei Nutzern minimieren.
    • Wegen der Verarbeitung von 84 TB an OCI-Inhalten ist unklar, welche Images genau wann entfernt werden.
    • Ab dem 28. August müssen für geschäftskritische Funktionen alternative Registries vorbereitet werden.
  • In der neuen Bitnami-Registry werden gehärtete Photon-Images unter denselben Namen wie die bisherigen Debian-Images hochgeladen.
  • Bestehende und neue Nutzer können mit den sicherheitsgehärteten Images auf die aktuellen Anforderungen der Open-Source-Welt reagieren.
  • Weitere Details zur Umstellung finden sich in den Bitnami-FAQ.

Verwandte Beiträge

2 Kommentare

 
jic5760 2025-08-31

Um Bitnami in der Community weiterzuführen, habe ich gestern Bitmoa erstellt.
Ziel ist es, Bitnami-Images mit minimalen Änderungen (etwa bei ENV) zu ersetzen.

https://github.com/bitmoa/containers (Images werden per GH Action gebaut)
https://github.com/bitmoa/charts
 
GN⁺ 2025-08-30
Hacker-News-Kommentare
  • Es ist schon etwas überraschend, dass man freie Software nur „verpackt“, selbst nichts beiträgt und dann offenbar nach Oracle-Art kommerzialisieren will. Das soll ihre Arbeit nicht kleinreden, aber ich frage mich, auf wie viel davon sie tatsächlich Urheberrechte geltend machen können. Meist sind die einzelnen Pakete nur ein paar Zeilen Bauanleitung, und es wirkt im Grunde so, als wolle man eine Befehlszeile wie make build urheberrechtlich schützen. Und wenn die Verteilung der erzeugten Binärdateien unter einer Open-Source-Lizenz steht, sollten die Nutzer doch auch Anspruch auf Quellcode, Build-Anleitung und das Recht zur Weiterverteilung haben.
    • Die von Bitnami erstellten Makefiles und Ähnliches sind allerdings Teile, in die erheblicher Aufwand geflossen ist, und unterschiedliche Software allein über Umgebungsvariablen nutzbar zu machen, ist keineswegs einfach. Ein Blick auf dieses Beispiel lohnt sich. Für einen Teil der Nutzerbasis ist eine kommerzielle Lizenz derzeit durchaus wertvoll.
    • Der eigentliche größere Wert könnte in den Helm charts liegen. Allerdings gibt es mit den offiziellen Images bereits Alternativen, sodass es keinen besonderen Grund gibt, zwingend Bitnamis Node- oder Postgres-Images zu verwenden. Deshalb frage ich mich, wie viele Leute die Helm charts von Bitnami tatsächlich genutzt haben.
  • Die von Bitnami bereitgestellten Hardened Images waren ein Zeichen von Goodwill und haben dabei geholfen, dort einen ersten Fuß in die Tür zu bekommen, wo sie wirklich gebraucht wurden. Aber auf dem Markt konnten sie mit besseren Optionen nicht konkurrieren. Dieser Wechsel zu einem „Subscription“-Modell ist keine Lösung, sondern wirkt eher wie aggressives Verkaufen. Terraform Cloud hat etwas Ähnliches gemacht, und dort sieht die Lage meiner Meinung nach auch nicht gut aus. Bitnamis Beitrag beschränkt sich faktisch auf ein paar zusätzliche Konfigurationsoptionen; gemessen an den OperatorFramework-Capabilities ist das höchstens Level 2 oder eher 1, siehe Referenz.
    • Ich finde es übertrieben, das als „aggressives Verkaufen“ zu bezeichnen, nur weil Bitnami etwas, das sie bislang kostenlos angeboten haben, nun einstellt und die Nutzer nach Ersatz suchen müssen. Schon dass sie es kostenlos bereitgestellt haben, ist etwas, wofür man dankbar sein kann.
    • Zu sagen, es sei aggressives Verkaufen, nur weil etwas nicht mehr kostenlos angeboten wird, ist eine extreme Formulierung. Es bleibt einfach nur das bedauernde Gefühl, dass man es jetzt selbst machen muss.
    • Es scheint etwas Verwirrung darüber zu geben, was Broadcom für ein Unternehmen ist. Broadcom interessiert sich nicht für „langfristige Gesundheit“. Wenn sie ein Produkt übernehmen, entlassen sie 90 % der Mitarbeiter und erhöhen Lizenz- und Supportkosten um das 2- bis 100-Fache. Sie nutzen aus, dass Fortune-500-Unternehmen nicht ohne Weiteres aussteigen können, und schöpfen dann über Verträge von etwa fünf Jahren kontinuierlich Geld ab. Selbst auf Marktreaktionen nehmen sie keine Rücksicht und gehen notfalls rechtlich dagegen vor; am Ende bleibt der Effekt der Preiserhöhung trotzdem bestehen.
    • 2025 funktioniert die Strategie für Infrastrukturunternehmen nicht mehr, sich erst Beliebtheit unter Entwicklern aufzubauen und diese später in Umsatz zu verwandeln. Man muss von Anfang an Umsatz machen, und am Ende bleibt nur der Enterprise-Markt als Ziel. Alle konkurrieren um genau diesen engen Markt.
    • Der Mehrwert, den sie hinzugefügt haben, ist sehr klein. Dass Nutzer jetzt trotzdem leiden, weil selbst das nur schwer zu ersetzen ist, sollte einem zu denken geben.
  • Am Ende hängt es auch mit CSR zusammen, und der Wechsel wird durch den CRA überhaupt erst möglich. Durch die Regulierung des EU Cyber Resilience Act könnte sich das Open-Source-Ökosystem stark verändern. Unternehmen, die auf Open Source basierende Produkte kommerziell anbieten, müssen künftig Sicherheits- und Dokumentationsvorgaben strikt einhalten. Für reine Open-Source-Projekte gilt das nicht, aber sobald gegen Geld verteilt wird, entsteht eine rechtliche Last. Am Ende scheint der Verkauf von Compliance-Frameworks als Service eine neue Chance zu sein.
    • Wegen des CRA muss man nicht zwingend nur kostenpflichtige Sicherheits-Images anbieten. Wenn man will, kann man sie auch kostenlos bereitstellen oder nur für die kommerzielle Nutzung Geld verlangen.
    • Wenn man Open Source plus Zusatzservices kommerziell verkauft, ist die Compliance-Arbeit gemäß CRA ohnehin Pflicht. Am Ende braucht man dafür bei Open und bei kommerziellen Angeboten denselben Aufwand.
  • Falls jemand eine Alternative braucht: Das Twistlock-Team hat Minimus gestartet. Es baut direkt aus dem Source und liefert kontinuierlich Images mit nahezu keinen Schwachstellen aus. Wie bei Bitnami gibt es auch hier einen Drop-in Replacement. Wenn ihr Fragen zu Nutzung, Tools oder Kundenbeispielen habt, gerne jederzeit fragen. Siehe auch diesen Vergleichs- und Infopost.
    • Das Anmeldeformular von Minimus unterscheidet zwischen „Privatperson“ und „Organisation“, aber die Eingabe eines Firmennamens ist verpflichtend. Das wirkt seltsam und sieht nach reinem Marketing aus.
    • Ich werde das Vergleichsbeispiel zwischen Minimus und Bitnami Secure Images aus dem Blog etwas verständlicher zusammenfassen: Bitnami Secure Images werden auf Photon aufgebaut, und bei Schwachstellen oder neuen Releases werden sie automatisch gebaut, getestet und verteilt. Nutzer müssen dann nur die neueste Version verwenden und brauchen sich weder um CVE-Monitoring noch um manuelle Patches zu kümmern.
    • Der Preis ist das größte Problem. Bei Chainguard und Docker Secure Images habe ich nach dem Preis schnell das Interesse verloren. Auf der Website von Minimus finde ich nirgends Preisangaben, daher liegt der Verdacht nahe, dass es wahrscheinlich zu teuer für die meisten sein wird.
    • Ich frage mich, ob Minimus ein Betriebssystem ist. Bitnami bleibt weiterhin ein Open-Source-Projekt, bei dem man Images direkt aus dem Source bauen kann.
    • Es wäre gut, wenn Minimus selbst einen docker-credential helper implementieren und ähnlich wie Chainguards docker-credential-cgr bereitstellen würde. Es sollte nicht bei dem Hinweis bleiben: „Docker unterstützt einen Credential Store, kümmert euch selbst darum.“ Siehe Referenz.
  • Wenn ich mir die Lizenzkosten ansehe, also mehr als 50.000 US-Dollar pro Jahr, bin ich klar nicht die Zielgruppe.
    • In der offiziellen Beschreibung steht zwar, BSI „demokratisiere Open-Source-Sicherheit und Compliance“, aber 50.000 US-Dollar sind meiner Meinung nach alles andere als „demokratisiert“.
    • Die Begriffe sind zwar etwas verwirrend, aber tatsächlich werden viele bislang kostenlose Images gerade in kostenpflichtige Angebote umgewandelt. Die Dockerfiles sind weiterhin verfügbar, und die Docker-Hub-Images kann man auch noch nutzen. Allerdings ist das kostenlose Angebot auf „Entwicklung“ beschränkt, also für den Produktiveinsatz eingeschränkt. Die eigentlichen „Secure“-Images werden auf Photon OS gebaut und durchlaufen zusätzliche Sicherheitsprozesse. Abseits des angebotenen Services wird aber nichts blockiert.
    • Das ist die einfachste Strategie, um Umsatz aus einer bestehenden Nutzerbasis zu ziehen, während man sie ohne Updates zurücklässt. Das hat schon eine gewisse Ironie.
  • Vor fast zwei Jahren wurde im Enterprise-Umfeld empfohlen, von Bitnami wegzugehen. Jetzt, wo dieses Projekt wohl gerade abgeschlossen wird, fühlt es sich gut an, richtig gelegen zu haben.
  • Zusammen mit den Änderungen bei den VMware-Lizenzen sieht es klar so aus, als wolle Broadcom den Platz von Oracle einnehmen. Es ist schade zu sehen, wie hart der Wettbewerb inzwischen geworden ist.
    • Ich bin schon gespannt(?), wie Broadcom das Spring-Ökosystem monetarisieren wird. Praktisch alle Großunternehmen nutzen Spring, daher erscheint es mir nur noch eine Frage der Zeit.
    • Broadcom ist in Wirklichkeit Avago Technologies, die 2015–2016 nur den Namen übernommen haben. Der eigentliche Bereich und das meiste IP des echten Broadcom wurden längst verkauft.
    • Wenn man weiß, wie „übel“ Broadcom in Wirklichkeit ist, wirkt selbst dieses Thema hier vielleicht fast harmlos. Trotzdem könnten Nutzer kurzfristig sogar davon profitieren.
    • Ich glaube nicht, dass viele der Bitnami-Ingenieure mit dieser Entscheidung wirklich einverstanden sind.
    • Solange es Microsoft gibt, konkurrieren Broadcom und Oracle nur um Platz zwei in der Rangliste des Bösen.
  • Softwareprojekte bestehen letztlich aus (1) Code, den man selbst pflegt oder dessen Wartung man bezahlt, und (2) aus Wegwerfcode, den man irgendwann durch eine inkompatible Version ersetzen muss. Auch das bloße Zusammensetzen von Wegwerfcode kann ein durchaus kluger Einsatz sein, aber wenn die Quellen der Abhängigkeiten Dritten gehören, sollte man niemals erwarten, dass diese sie quasi dauerhaft pflegen. Echtes Risikomanagement heißt, davon auszugehen, dass die Lebensdauer des eigenen Projekts kürzer ist als die seiner Abhängigkeiten.
  • Schade, dass Broadcom nicht einmal einfaches Padding für Mobilgeräte ordentlich hinbekommt. Andererseits könnte man auch einfach docker.io/bsi separat anlegen und /bitnami in der alten Form bestehen lassen; dann würde nichts kaputtgehen, und die Nutzer könnten selbst umsteigen. Gleichzeitig ließe sich auf natürliche Weise erklären, warum dort keine Upgrades mehr erfolgen.
    • Wenn Bitnami kostenlose Sicherheitsupdates einstellt, hätte man die Nutzer explizit dem Risiko zustimmen lassen sollen. Nach ausreichend Vorankündigung wäre es auch eine brauchbare Lösung gewesen, /bitnami nach /bitnamilegacy zu verschieben.
    • Der Name „bitnami“ selbst hat Markenwert, also ist es aus geschäftlicher Sicht nur logisch, diese Benennung auch beim Verkauf eines neuen Services weiterzuverwenden.
    • Das Problem mit Broadcoms Padding fühlt sich ähnlich an wie das hoffnungslos veraltete UI-Design von Rally.
  • Ich kann die Image- und Paketkonventionen von Bitnami überhaupt nicht nachvollziehen. In der Praxis war mir das viel zu komplex, und die eigenen Regeln waren eher lästig. Statt einfacher Pakete auf normaler Basis ist alles in einer seltsamen Struktur aufgebaut, und sobald man etwas ändern will, herrscht völliges Chaos.
    • Sie ignorieren ihre eigenen Konventionen, legen komplexe Skripte obendrauf, und jedes einzelne Image kann man nur nutzen, wenn man extra dessen Dokumentation liest. Dass das nicht mit der offiziellen Standarddokumentation übereinstimmt, war frustrierend.
    • Früher habe ich Bitnami-Images genutzt, um leicht an Base Images zu kommen, die rootless laufen. Damals war rootless etwa bei postgres in den offiziellen Repositories schwer umzusetzen. Allerdings waren bei jedem Bitnami-Image UID oder Konfigurationspfade anders, sodass man immer erst das Dockerfile im Detail lesen musste.
    • Bitnami war ursprünglich beliebt, um WordPress unter Windows zu betreiben. Sie machten es möglich, es direkt auf Windows Server zu nutzen, und damals war das tatsächlich nützlich. Heute würde man dafür vielleicht gefeuert werden, aber seinerzeit hatte sich Linux noch nicht so breit durchgesetzt, also war das ein sinnvoller Dienst.
    • Ich frage mich, ob es gute Ressourcen gibt, an denen man sich bei solchen Packaging-Konventionen orientieren kann. Mein Eindruck ist, dass die meisten die offiziellen Images eines Projekts als Basis nehmen, sie dann nach Bedarf anpassen und daraus ihre eigenen Images bauen.