Stackable Data Platform 26.7: Sicherheit, SBOMs und flexible Registries

Fokus auf Qualität und Supply-Chain-Sicherheit

Mit der Veröffentlichung der Version 26.7 schlägt die Stackable Data Platform einen neuen Kurs ein. Anstatt den Fokus primär auf neue Produktfeatures zu legen, konzentriert sich das Unternehmen bei diesem Release auf die Qualitätssicherung der modularen, Kubernetes-basierten Open-Source-Plattform. Die Entwickler haben nach eigenen Angaben technische Schulden abgebaut, CI-Pipelines stabilisiert und instabile Tests bereinigt.

Neben diesen internen Optimierungen wurden zahlreiche Software-Komponenten aktualisiert. Dazu zählen unter anderem Apache Airflow 3.2.2, Apache Superset 6.1.0, OpenSearch 3.6.0, Trino 481, Apache NiFi 2.9.0 sowie Open Policy Agent 1.16.2. Auch die LTS-Versionen Apache Spark 4.1.2 und Apache Druid 37.0.0 sind enthalten. Ein wesentlicher Aspekt des Updates ist die Behebung von 133 Schwachstellen, darunter 10 kritische und 62 als hoch eingestufte CVEs. Die Plattform unterstützt nun Kubernetes-Versionen von 1.31 bis 1.36 sowie Red Hat OpenShift 4.18 bis 4.22.

Dynamische Registry-Auswahl: Ein entscheidender Umbruch

Eine der folgenreichsten Änderungen betrifft die Art und Weise, wie Produktimages bezogen werden. Bisher war die Registry `oci.stackable.tech` fest im Code verankert, was in Air-Gap-Umgebungen oder bei der Nutzung interner Mirror-Registries oft komplexe Workarounds erforderte. Mit Version 26.7 führt Stackable eine dynamische Konfiguration ein.

Über den neuen CLI-Parameter `--image-repository` oder die Umgebungsvariable `IMAGE_REPOSITORY` können Administratoren nun flexibel festlegen, aus welcher Quelle die Images geladen werden sollen. Bei Installationen über Helm-Charts oder den Operator Lifecycle Manager (OLM) erkennt die Plattform die Herkunft des Operators automatisch und passt die Registry für die Produktimages entsprechend an.

Wichtige Hinweise für den Umstieg

Für Nutzer, die Operatoren außerhalb von Helm oder OLM betreiben – etwa via Kustomize, ArgoCD oder eigene Deployment-YAMLs – stellt diese Änderung einen sogenannten „Breaking Change“ dar. Hier ist eine manuelle Anpassung im `args`-Block des Operator-Containers zwingend erforderlich. Auch bei eigenen Helm-Charts muss der Wert `image.repository` angepasst werden, da dieser den Operatornamen nicht mehr enthalten darf. Ein Testlauf in einer isolierten Umgebung vor dem produktiven Upgrade wird dringend empfohlen, um ImagePull-Fehler zu vermeiden.

Transparenz durch SLSA-Provenance und SBOMs

Ein weiterer Schwerpunkt liegt auf der Sicherheit der Lieferkette. Ab Version 26.7 sind alle Container-Images von Stackable mit einer SLSA-Build-Provenance-Attestation (Supply-chain Levels for Software Artifacts) ausgestattet. Durch den Einsatz des `slsa-github-generator` wird SLSA Level 3 erreicht. Die Signierung erfolgt „keyless“ über Sigstore, wobei GitHub Actions als OIDC-Identity-Provider dient.

Zusätzlich zu den bereits existierenden CycloneDX-SBOMs (Software Bill of Materials) wird nun für jedes Image eine SBOM im SPDX-Format als OCI-Attestation bereitgestellt. Diese Maßnahmen sind insbesondere für Betreiber in regulierten Branchen wie dem Finanz- oder Gesundheitswesen von Bedeutung. Sie ermöglichen den Nachweis der Herkunft und Integrität von Software-Artefakten, was Anforderungen aus dem EU Cyber Resilience Act, NIS2 oder ISO 27001 unterstützt.

Zentraler Zugriff über den Stackable Hub

Mit dem neuen Stackable Hub unter `hub.stackable.tech` wurde eine zentrale Anlaufstelle geschaffen, die die Lücke zwischen Dokumentation und technischer Umsetzung schließt. Der öffentliche Katalog bietet:

* Eine Übersicht aller SDP-Releases inklusive Support-Zeiträumen.

* Eine Komponenten-Timeline mit exakten Versionen der enthaltenen Open-Source-Produkte.

* Eine CRD-Referenz mit vollständigen .spec-Schemas.

Für die Automatisierung steht eine CORS-fähige JSON-API zur Verfügung, die ohne Authentifizierung direkt in CI-Skripte oder Tools eingebunden werden kann. Zudem bietet ein `llms.txt`-Endpunkt eine maschinenlesbare Zusammenfassung, die es KI-Assistenten erleichtert, aktuelle SDP-Daten in einen Kontext zu setzen.

Die Kombination aus dynamischer Registry-Konfiguration, kryptografisch prüfbaren Herkunftsnachweisen und dem neuen Hub unterstreicht das Ziel des Anbieters, die Plattform noch portabler und für automatisierte, souveräne Architekturen besser nutzbar zu machen.