Stackable data platform 26.7: security, SBOMs and flexible registries

Stackable has released version 26.7 of its Stackable Data Platform, marking a departure from its usual release schedule. Instead of introducing new product features, the update focuses on quality assurance for its modular, Kubernetes-based open-source platform. The changes aim to reduce technical debt, stabilize continuous integration pipelines, and clean up unstable tests. Improvements include dynamic registry selection, enhanced supply-chain security, and the introduction of a central directory called Stackable Hub. While these updates may appear subtle, they are intended to benefit operators managing regulated infrastructure and those who wish to deploy outside standard pathways. The release includes several updates to core components such as 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, and the long-term support versions Apache Spark 4.1.2 and Apache Druid 37.0.0. Additionally, 133 vulnerabilities, 10 critical and 62 high-severity CVEs, have been addressed. The platform now supports Kubernetes versions 1.31 through 1.36 and Red Hat OpenShift 4.18 through 4.22. One of the most impactful changes involves how operators retrieve their product images. Previously, the registry oci.stackable.tech was hard-coded into the platform’s configuration. Adjustments for air-gapped environments or internal mirror registries required manual edits via Helm values or node-level containerd configurations, a workaround that became increasingly cumbersome as the platform scaled. In version 26.7, Stackable replaces this logic with a configurable mechanism. Operators can now specify the image repository using the CLI parameter --image-repository or the environment variable IMAGE_REPOSITORY. When installing an operator via Helm chart or OLM manifest, the platform automatically sets this value based on the registry from which the operator itself originates. For example, an operator sourced from quay.io/stackable will fetch its product images from quay.io by default. Stackable will now publish its artifacts, including operator Helm charts, directly from CI pipelines to quay.io, eliminating the need for manual mirroring. For installations outside of Helm or OLM, this change represents a breaking update. Users deploying operators manually via custom YAML files, Kustomize, or ArgoCD must explicitly set --image-repository within the operator container’s arguments block. This could look like --image-repository=oci.stackable.tech/sdp or point to an internal mirror registry. Those maintaining their own Helm charts must also adjust the image.repository field, removing the operator name. Instead of oci.stackable.tech/sdp/airflow-operator, the new format is simply oci.stackable.tech/sdp. Failure to make these adjustments results in ImagePull errors, causing pods to fail during startup. A test deployment in a staging environment before upgrading to production is strongly recommended. This shift moves registry portability from product-specific workarounds into platform-wide logic. For air-gapped scenarios, the IMAGE_REPOSITORY variable can be directed to an internal registry, provided the product images have been consistently mirrored there, an advantage for sovereign, interoperable architectures. The second major theme of the update centers around SLSA provenance and SPDX SBOMs, aiming to enhance traceability along the software supply chain. These additions provide greater transparency and control over dependencies, aligning with industry standards for secure and compliant operations.