Stackable Data Platform 26.7: Sicherheit, SBOMs und flexible Registries

7 seiner Stackable Data Platform, was eine Abweichung von seinem üblichen Veröffentlichungsplan bedeutet. Statt neue Produktfunktionen einzuführen, konzentriert sich das Update auf die Qualitätssicherung für seine modulare, auf Kubernetes basierende Open-Source-Plattform. Die Änderungen zielen darauf ab, technische Schulden zu reduzieren, kontinuierliche Integrationspipelines zu stabilisieren und instabile Tests zu beseitigen. Verbesserungen umfassen die dynamische Registrierung, verbesserte Lieferkettensicherheit und die Einführung eines zentralen Verzeichnisses namens Stackable Hub. Diese Updates mögen zwar subtil erscheinen, aber sie sollen den Betreibern zugute kommen, die regulierte Infrastruktur verwalten, und denen, die außerhalb der Standardwege einsetzen möchten.

Zusätzlich wurden 133 Schwachstellen 1010 kritisch und 62 hochgradig schwere CVEs behoben. 22. Eine der wirkungsvollsten Änderungen betrifft die Art und Weise, wie Betreiber ihre Produktbilder abrufen. Tech wurde in die Plattformkonfiguration fest codiert. Anpassungen für Luftlücke-Umgebungen oder interne Spiegelregister erforderten manuelle Bearbeitungen über Helm-Werte oder Konfigurationen auf Knoten-Ebene, ein Workaround, der mit der Skalierung der Plattform zunehmend umständlicher wurde.

Bei der Installation eines Operators über Helm-Chart oder OLM-Manifest setzt die Plattform diesen Wert automatisch basierend auf der Registrierung, aus der der Operator selbst stammt. io als Standard. io, wodurch die Notwendigkeit einer manuellen Spiegelung entfällt. Für Installationen außerhalb von Helm oder OLM stellt diese Änderung ein Breaking-Update dar. Benutzer, die Operatoren manuell über benutzerdefinierte YAML-Dateien, Kustomize oder ArgoCD bereitstellen, müssen ausdrücklich --image-repository innerhalb des Operator-Containers setzen. tech/sdp oder auf ein internes Spiegelregister verweisen. Repository-Feld, wobei der Name des Operators entfernt wird. tech/sdp. Wenn diese Anpassungen nicht vorgenommen werden, entstehen ImagePull-Fehler, wodurch die Pods beim Start ausfallen.

Eine Testbereitstellung in einer Staging-Umgebung vor dem Upgrade zur Produktion wird dringend empfohlen. Diese Verschiebung verschiebt die Portabilität der Registrierung von produktspezifischen Workarounds in eine plattformweite Logik. Für air-gapped-Szenarien kann die IMAGE_REPOSITORY-Variable auf eine interne Registrierung gerichtet werden, vorausgesetzt, die Produktbilder wurden dort konsistent gespiegelt, ein Vorteil für souveräne, interoperable Architekturen. Das zweite Hauptthema der Aktualisierung konzentriert sich auf die Herkunft von SLSA und SPDX SBOMs, mit dem Ziel, die Rückverfolgbarkeit entlang der Software-Lieferkette zu verbessern.

Diese Ergänzungen ermöglichen eine größere Transparenz und Kontrolle über Abhängigkeiten und entsprechen den Branchenstandards für sichere und konforme Operationen.