MinIO: Source-Only Distribution und keine aktive Weiterentwicklung

Am 15. Oktober kündigte das Unternehmen MinIO an, künftig nur noch den Source-Code ihres populären Open-Source Object Storage Systems MinIO über GitHub bereitzustellen . Es werden keine Container-Images mehr veröffentlicht.

Diese Änderung wurde zunächst über eine Aktualisierung der ReadMe-Datei im GitHub-Repository bekanntgegeben und durch Maintainer in verschiedenen GitHub-Issues bestätigt. Für Nutzer bedeutet dies, dass sie künftig selbst Container-Images erstellen müssen, um MinIO in ihren eigenen Infrastrukturen als Container bzw. Kubernetes Pod betreiben zu können.

Weiterhin gaben die Maintainer bekannt, dass das Projekt ab sofort nur noch mit Bugfixes und CVE-Sicherheitsupdates gepflegt wird. Es werden keine neuen Features entwickelt. (Siehe hierzu diesen GitHub-Kommentar)

Der Zeitpunkt dieser Änderung ist besonders kritisch, da zu diesem Zeitpunkt eine schwerwiegende Sicherheitslücke entdeckt wurde. Die bekannte Schwachstelle (Beschrieben in diesem Issue auf GitHub) betrifft eine kritische Sicherheitslücke, die potenziell ausgenutzt werden kann, um Kontrolle über betroffene Instanzen zu erlangen. Das stoppen der Container-Image Veröffentlichung hat kurz vor dieser Bekanntmachung stattgefunden, sodass jetzt alle Instanzen, die von dieser Sicherheitslücke betroffen sind kein Update bekommen werden, ohne dass ein Administrator eine Migration durchführt.

Da die Container-Images, die bislang als Ready-to-Use-Lösung dienten, nun nicht mehr veröffentlicht werden, ist es für Nutzer schwieriger, schnell und unkompliziert Sicherheitsupdates zu deployen. Damit erhöht sich das Risiko für betroffene Deployments erheblich, da sie nun eigene Images erstellen müssen, um die neuesten Patches zu integrieren.

Viele Nutzer haben inzwischen erkannt, dass Handlungsbedarf besteht, um weiterhin sicher mit MinIO arbeiten zu können. Daher haben sie inzwischen eigene Container-Images erstellt und veröffentlichen diese automatisiert bei jedem neuen Release von MinIO. Auch wir haben diese Entwicklung proaktiv aufgegriffen: Unser eigenes Container-Image (GitHub Repository) wird direkt in unserem Helm-Chart integriert (Siehe Helm-Charts). So stellen wir sicher, dass bei Deployments stets die neuesten Versionen genutzt werden, inklusive aller aktuellen Sicherheitsupdates. Damit kannst du auch weiterhin schnell auf Sicherheitslücken reagieren und deine MinIO-Instanzen aktuell halten, ohne den manuellen Aufwand, eigene Builds ständig zu pflegen.

Wenn du ein Helm-Chart für dein MinIO-Deployment verwendest, kannst du dieses ganz bequem durch unser eigenes Helm-Chart ersetzen. Dabei bleiben deine persistenten Daten unberührt, sodass du keine aufwändigen Migrationen durchführen musst. Die Konfiguration unseres Helm-Charts ist in der Regel sehr ähnlich zu anderen gängigen Helm-Charts, sodass du viele Einstellungen und Werte problemlos übernehmen kannst. In der ReadMe-Datei unseres Repositories findest du detaillierte Beispielkonfigurationen sowie eine vollständige Beschreibung aller verfügbaren Parameter. So kannst du dein System schnell, sicher und ohne Datenverluste auf die neue Lösung umstellen.

Eine weitere Option wäre die Migration von MinIO auf einen anderen S3-kompatiblen Object Storage. Dies kann eine sinnvolle Lösung sein, um eine kontinuierliche und unterstützte Umgebung zu gewährleisten. Im nächsten Abschnitt stellen wir dir einige der bekanntesten Alternativen vor, die du in Betracht ziehen kannst.

Wenn du überlegst, dein MinIO-Deployment durch eine alternative Storage-Lösung zu ersetzen, haben wir eine kompakte Übersicht für dich zusammengestellt. Bitte beachte: Die meisten dieser Anwendungen befinden sich aktuell noch in intensiver Entwicklung. Daher können sie möglicherweise Fehler aufweisen oder Änderungen an Funktionalität und Konfiguration erfordern.

• RustFS (https://rustfs.com)
  RustFS ist ein modernes, hochperformantes, dateibasiertes Storage-System, das in der Programmiersprache Rust geschrieben wurde. Es ist darauf ausgelegt, eine sichere, skalierbare und effiziente Alternative für Object Storage-Implementierungen zu bieten. RustFS zeichnet sich durch seine einfache API, geringe Latenz und Unterstützung für Verteilung und Replikation aus.

• Garage (https://garagehq.deuxfleurs.fr)

  Garage ist ein einfaches, skalierbares und hochverfügbares Object Storage-System, das auf der S3-API basiert. Es wurde entwickelt, um eine flexible Alternative zu komplexen Storage-Lösungen zu bieten, insbesondere für Embedded-Devices, Edge-Computing und kleine bis mittlere Cloud-Umgebungen. Garage ist bekannt für seine einfache Handhabung, geringe Ressourcennutzung und schnellen Deployment-Prozess, wodurch es eine attraktive Wahl für Anwendungen ist, die eine unkomplizierte S3-kompatible Speicherung benötigen.

• SeaweedFS (https://github.com/seaweedfs/seaweedfs)

  SeaweedFS ist ein skalierbares, hochverfügbares verteiltes Dateisystem, das speziell für große Mengen unstrukturierter Daten geeignet ist. Es bietet eine einfache Architektur, die für horizontale Skalierung optimiert ist, und unterstützt sowohl Block- als auch Objekt-Storage-Modelle. SeaweedFS kennt geringe Latenzzeiten und eine effiziente Nutzung des Speicherplatzes.

• Managed Object Stores

  Durch Anbieter wie AWS, Azure oder sogar MinIO selbst, kannst du einen Managed Object Store buchen. Wie bei allen Managed Services musst du dich dabei nicht um das Hosten kümmern und kannst direkt mit der Anbindung anfangen.