Für die Veröffentlichung der neuen Version 26.7 seiner Stackable Data Platform weicht das gleichnamige Unternehmen vom üblichen Release-Rhythmus ab. Statt neuer Produktfeatures stand dabei laut Ankündigung die Qualitätssicherung der modularen, auf Kubernetes basierenden Open-Source-Plattform im Mittelpunkt. SDP 26.7 zeichnet sich demnach durch den Abbau technischer Schulden, die Stabilisierung von CI-Pipelines und das Bereinigen instabiler Tests aus. Die Verbesserungen reichen von der dynamischen Registry-Auswahl über erhöhte Supply-Chain-Sicherheit bis zum neuen zentralen Verzeichnis, dem Stackable Hub. Zwar liegen die wichtigsten Neuerungen somit eher unter der Oberfläche. Sie sollen aber insbesondere Betreibern regulierter Infrastrukturen und all jenen zugutekommen, die Operatoren außerhalb des Standardwegs installieren wollen.
Laut Blogbeitrag zum neuen Release liefert Stackable dennoch eine Reihe von Updates, darunter Apache Airflow 3.2.2, Apache Superset 6.1.0, OpenSearch 3.6.0, Trino 481, Apache NiFi 2.9.0, Open Policy Agent 1.16.2 sowie die LTS-Versionen Apache Spark 4.1.2 und Apache Druid 37.0.0. Zudem wurden 133 Schwachstellen behoben – davon 10 kritische und 62 als hoch eingestufte CVEs. Unterstützt werden Kubernetes 1.31 bis 1.36 sowie Red Hat OpenShift 4.18 bis 4.22.
Die CLC-Konferenz vom 11. bis 12. November 2026 in Mannheim legt den Fokus darauf, wie Agentic AI die Arbeit von Developern, Software-Architekten, DevOps- und Platform Engineers verändert und sich digitale Souveränität nachhaltig erreichen lässt.
Jetzt Tickets zum Frühbucherpreis sichern.
Dynamische Registry-Auswahl – ein Breaking Change mit Folgen
Die folgenreichste Änderung betrifft die Art, wie Operatoren ihre Produktimages beziehen. Bisher war die Registry oci.stackable.tech fest im Code hinterlegt. Anpassungen für Air-Gap-Umgebungen oder interne Mirror-Registries erforderten Helm-Werte pro Produkt oder Eingriffe in die Containerd-Konfiguration auf Knotenebene – ein Workaround, der mit wachsender Plattformgröße zunehmend unhandlich wurde.
Ab Version 26.7 ersetzt Stackable diese Logik durch einen konfigurierbaren Mechanismus. Über den neuen CLI-Parameter --image-repository beziehungsweise die Umgebungsvariable IMAGE_REPOSITORY bestimmen die Operatoren, woher sie ihre Produktimages beziehen. Wird ein Operator über den Helm-Chart oder das OLM-Manifest (Operator Lifecycle Manager) installiert, setzt die Plattform diesen Wert automatisch passend zur Registry, aus der der Operator selbst stammt. Ein Operator, der aus quay.io/stackable kommt, zieht seine Produktimages damit automatisch ebenfalls von quay.io. Stackable veröffentlicht seine Artefakte – inklusive der Operator-Helm-Charts – künftig direkt aus den CI-Pipelines nach quay.io, statt sie manuell zu spiegeln.
Für Installationen außerhalb von Helm oder OLM ist das ein echter Breaking Change. Wer Operatoren per eigenem Deployment-YAML, Kustomize oder ArgoCD betreibt, muss --image-repository explizit im args-Block des Operator-Containers setzen – etwa als --image-repository=oci.stackable.tech/sdp oder mit dem Pfad einer internen Mirror-Registry. Wer eigene Helm-Charts pflegt, muss zusätzlich den Wert image.repository anpassen: Er darf den Operatornamen nicht mehr enthalten. Statt oci.stackable.tech/sdp/airflow-operator lautet der Wert künftig nur noch oci.stackable.tech/sdp. Fehlt die Anpassung, finden die Operatoren ihre Images nicht mehr – die Pods bleiben mit ImagePull-Fehlern hängen. Ein Testlauf in einer separaten Umgebung vor dem Produktiv-Upgrade ist dringend empfohlen.
Unterm Strich wandert die Registry-Portabilität damit von produktspezifischen Workarounds in die Plattformlogik. Für Air-Gap-Szenarien lässt sich IMAGE_REPOSITORY gezielt auf eine interne Registry lenken, sofern die Produktimages konsistent dorthin gespiegelt sind – ein Gewinn für souveräne, interoperable Architekturen.
SLSA-Provenance und SPDX-SBOMs: Nachvollziehbare Lieferkette
Der zweite große Themenblock ist die Supply-Chain-Sicherheit. Ab Version 26.7 liefern alle Container-Images von Stackable – sowohl Produkt- als auch Operator-Images – eine SLSA-Build-Provenance-Attestation (Supply-chain Levels for Software Artifacts). Die Provenance (Herkunft) entsteht über den slsa-github-generator und erreicht SLSA Level 3: Ein vertrauenswürdiger, vom Projekt-Build getrennter Builder erzeugt und signiert die Attestation, sodass ein kompromittierter Buildjob sie nicht fälschen kann. Signiert wird keyless über Sigstore mit GitHub Actions als OIDC-Identity-Provider.
Ergänzend zu den bereits vorhandenen CycloneDX-SBOMs hängt nun an jedem Image auch eine SBOM im SPDX-Format als OCI-Attestation. Zur Verifikation empfiehlt Stackable den slsa-verifier, der stets gegen die Digest-Referenz statt gegen Tags arbeitet. Alternativ lässt sich cosign einsetzen.
Für Betreiber in regulierten Sektoren wie dem Finanz- und Gesundheitswesen sowie der öffentlichen Verwaltung ist das mehr als eine Formalie. Anforderungen aus NIS2, dem EU Cyber Resilience Act oder ISO 27001 verlangen zunehmend den Nachweis, woher Software-Artefakte stammen und ob sie unterwegs manipuliert wurden. Mit der Provenance lässt sich für jedes Image belegen, aus welchem Git-Repository und Commit heraus es gebaut wurde und welche Build-Infrastruktur beteiligt war. Die SPDX-SBOMs erfassen jede enthaltene Bibliothek samt Version und damit die Grundlage für automatisierte CVE-Scans und Policy-Prüfungen. Admission-Controller wie Kyverno oder OPA/Gatekeeper lassen sich so konfigurieren, dass nur Images mit gültiger Signatur und passenden Attestationen in den Cluster gelangen.
Stackable Hub: Ein zentrales Verzeichnis für die Plattform
Neu ist der Stackable Hub unter hub.stackable.tech. Der öffentliche, schreibgeschützte Katalog ist als zentrale Anlaufstelle für alle Fragen rund um SDP-Releases gedacht – und schließt damit eine Lücke zwischen Dokumentation und tatsächlich ausgeliefertem Stand.
Der Hub bietet drei durchsuchbare Bereiche: eine Übersicht aller veröffentlichten SDP-Releases mit Erscheinungs- und End-of-Support-Datum, eine Komponenten-Timeline mit den exakten Versionen jedes enthaltenen Open-Source-Produkts sowie eine CRD-Referenz mit vollständigen .spec-Schemas, die sich nach SDP-Release filtern lassen. Wer wissen will, welche Apache-Kafka-Version in Release 25.11 enthalten war oder wie das Schema eines TrinoCluster-Objekts in Version 26.3 aussieht, findet die Antwort dort ohne Deployment.
Für Tooling und Automatisierung steht eine CORS-fähige JSON-API unter /api/v1/ bereit, ohne Authentifizierung, direkt einbindbar in CI-Jobs, Skripte und MCP-Server. Zusätzlich steht für LLM-Tools ein llms.txt-Endpunkt als Klartext-Zusammenfassung des Hubs bereit, damit ein Assistent aktuelle SDP-Daten in den Kontext einordnen kann, anstatt Versionsnummern zu erraten. Der bisherige CRD- und SBOM-Browser soll künftig in den Hub überführt werden.
Ein Schritt zu mehr Nachvollziehbarkeit und Portabilität
Den drei zentralen Neuerungen ist eines gemeinsam: die dynamische Registry-Auswahl, SLSA-Provenance mit SPDX-SBOMs und der Stackable Hub lassen die Stoßrichtung des Anbieters erkennen, zu noch mehr Nachvollziehbarkeit und Portabilität der Plattform. Weniger Abhängigkeit von fest verdrahteten Defaults, dafür mehr kryptografisch prüfbare Herkunftsnachweise und maschinenlesbare Metadaten für die eigene Automatisierung. Ein kompletter Überblick aller Änderungen in SDP 26.7 findet sich in den Release Notes.
(map)
English (US) ·