Yığınlanabilir Veri Platformu 26.7: Esnek güvenlik, SBOM ve kayıtlar

Aynı isimli şirket, Yığınlanabilir Veri Platformunun yeni 26.7 sürümünün piyasaya sürülmesi için her zamanki çıkış hızından sapıyor. Duyuruya göre, yeni ürün özellikleri yerine modüler Kubernetes tabanlı açık kaynak platformun kalite güvencesine odaklanıldı. Bu nedenle SDP 26.7, teknik borcun azaltılması, CI boru hatlarının stabilizasyonu ve dengesiz testlerin temizlenmesi ile karakterize edilir. İyileştirmeler, dinamik kayıt defteri seçiminden artırılmış tedarik zinciri güvenliğine ve yeni bir merkezi dizin olan İstiflenebilir Hub'a kadar uzanır. En önemli yenilikler yüzeyin daha altında yatıyor. Ancak bunların öncelikle düzenlenmiş altyapı operatörlerine ve standart rotanın dışında operatör kurmak isteyen herkese fayda sağlaması amaçlanıyor.

Yeni sürümle ilgili blog gönderisine göre Stackable, 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'nin yanı sıra LTS'nin Apache Spark 4.1.2 ve Apache Druid 37.0.0 sürümlerini de içeren bir dizi güncelleme sağlamaya devam ediyor. Ek olarak, 10'u kritik ve 62'si yüksek CVE olarak sınıflandırılan 133 güvenlik açığı düzeltildi. Kubernetes 1.31 – 1.36 ve Red Hat OpenShift 4.18 – 4.22 desteklenmektedir.

Dinamik kayıt seçimi: Sonuçları olan radikal bir değişiklik

En büyük değişiklik, operatörlerin ürün görsellerini satın alma şeklidir. Şimdiye kadar oci.stackable.tech kayıt defteri kalıcı olarak kodda saklanıyordu. Hava boşluklu ortamlara veya dahili ayna kayıtlarına yönelik özelleştirmeler, ürün başına Helm değerleri veya düğüm düzeyinde kapsayıcı yapılandırma çalışması gerektiriyordu; bu, platformun boyutu büyüdükçe giderek hantal hale gelen bir geçici çözümdü.

Stackable, 26.7 sürümünden itibaren bu mantığı yapılandırılabilir bir mekanizmayla değiştiriyor. Yeni CLI parametresi hakkında bilgi edinin --image-repository veya ortam değişkeni IMAGE_REPOSITORY operatörler ürün görsellerini nereden alacaklarını belirler. Helm grafiği veya OLM (Operatör Yaşam Döngüsü Yöneticisi) bildirimi aracılığıyla bir operatör yüklenirse platform, bu değeri, operatörün geldiği kayıt defteriyle eşleşecek şekilde otomatik olarak ayarlar. quay.io/stackable adresinden gelen bir operatör, ürün görsellerini quay.io'dan otomatik olarak çeker. Gelecekte Stackable, operatör kask tabloları da dahil olmak üzere eserlerini manuel olarak yansıtmak yerine doğrudan CI boru hatlarından quay.io'ya yayınlayacak.

Helm veya OLM dışındaki kurulumlar için bu, gerçekten oyunun kurallarını değiştiren bir değişikliktir. Operatörleri kendi YAML, Kustomize veya ArgoCD dağıtımını kullanarak yöneten herkes --image-repository açıkça args– Operatör konteyner kilidini ayarlayın, örneğin --image-repository=oci.stackable.tech/sdp veya dahili ayna kayıt defterinin yolu ile. Kask tablolarınızı kendiniz yönetiyorsanız değeri de girmeniz gerekir. image.repository adapt: ​​Artık operatör adını içeremez. Yerine oci.stackable.tech/sdp/airflow-operator değer yalnızca gelecekte olacaktır oci.stackable.tech/sdp. Ayarlama eksikse operatörler artık görüntülerini bulamazlar: bölmeler kendilerinde kalır ImagePull– Hatalar çöküyor. Üretimi yükseltmeden önce ayrı bir ortamda test edilmesi önemle tavsiye edilir.

Önemli olan, kayıt defteri taşınabilirliğinin ürüne özgü geçici çözümlerden platform mantığına geçmesidir. Hava boşluğu senaryoları için şunları yapabilirsiniz IMAGE_REPOSITORY Ürün görselleri sürekli olarak orada yansıtıldığı sürece dahili bir kaydı hedef alır; bu, egemen, birlikte çalışabilen mimariler için bir nimettir.

SLSA ve SBOM SPDX kaynağı: izlenebilir tedarik zinciri

İkinci önemli konu ise tedarik zinciri güvenliğidir. Sürüm 26.7'den başlayarak, hem ürün hem de operatör görselleri olmak üzere tüm İstiflenebilir Konteyner görselleri, Yazılım Eserleri için Tedarik Zinciri Düzeyleri (SLSA) yapısından kaynak kanıtı sağlar. Kaynak, slsa-github oluşturucusu kullanılarak oluşturulur ve SLSA seviye 3'e ulaşır: Proje yapısından ayrı, güvenilir bir kurucu, güvenliği ihlal edilmiş bir derleme işinin onu taklit edememesi için tasdiki oluşturur ve imzalar. İmzalama, OIDC kimlik sağlayıcısı GitHub Actions ile Sigstore aracılığıyla anahtarsızdır.

Mevcut CycloneDX SBOM'lara ek olarak, artık her görüntüde OCI onayı olarak eklenen bir SPDX formatlı SBOM bulunmaktadır. Doğrulama için Stackable, etiketler yerine her zaman özet referansıyla çalışan slsa-verifier'ı önerir. Alternatif olarak cosign'ı kullanabilirsiniz.

Finans, sağlık ve kamu yönetimi gibi düzenlemeye tabi sektörlerdeki operatörler için bu, basit bir formaliteden daha fazlasıdır. NIS2, AB Siber Dayanıklılık Yasası veya ISO 27001 gereklilikleri, yazılım eserlerinin nereden geldiğine ve bu süreçte manipüle edilip edilmediğine dair giderek daha fazla kanıt gerektirmektedir. Kaynak, her görüntü için hangi Git deposundan oluşturulduğunu ve hangi bina altyapısının dahil olduğunu göstermek için kullanılabilir. SPDX SBOM'lar dahil edilen her kitaplığı ve sürümü kaydederek otomatik CVE taramaları ve politika kontrolleri için temel sağlar. Kyverno veya OPA/Gatekeeper gibi giriş denetleyicileri, yalnızca geçerli bir imzaya ve uygun tasdike sahip görüntülerin kümeye gireceği şekilde yapılandırılabilir.

İstiflenebilir Hub: Platform için merkezi bir dizin

İstiflenebilir Hub, hub.stackable.tech'te yenidir. Salt okunur genel kataloğun, SDP sürümleriyle ilgili tüm sorular için merkezi bir iletişim noktası olması ve böylece belgeler ile teslim edilen gerçek sürüm arasındaki boşluğu doldurması amaçlanmaktadır.

Merkez, aranabilir üç alan sunar: yayınlanma ve destek sonu tarihleriyle birlikte yayınlanan tüm SDP sürümlerine genel bakış, dahil edilen her açık kaynak ürünün tam sürümlerini içeren bir bileşen zaman çizelgesi ve SDP sürümüne göre filtrelenebilen eksiksiz .spec şemalarını içeren bir CRD referansı. 25.11 sürümüne hangi Apache Kafka sürümünün dahil edildiğini veya 26.3 sürümünde bir TrinoCluster nesnesinin şemasının nasıl göründüğünü bilmek istiyorsanız, cevabı orada dağıtım olmadan bulacaksınız.

Araçlar ve otomasyon için CORS uyumlu bir JSON API, kimlik doğrulaması olmadan /api/v1/'de mevcuttur ve doğrudan CI işlerine, komut dosyalarına ve MCP sunucularına entegre edilebilir. Ek olarak, LLM araçları için merkezin düz metin özeti olarak bir llms.txt uç noktası mevcuttur; böylece bir asistan, sürüm numaralarını tahmin etmek yerine mevcut SDP verilerini bağlama yerleştirebilir. Önceki CRD ve SBOM tarayıcıları gelecekte hub'a taşınacaktır.

Daha fazla izlenebilirlik ve taşınabilirliğe doğru bir adım

Üç merkezi yeniliğin ortak bir noktası var: dinamik kayıt seçimi, SPDX SBOM ile SLSA kaynağı ve istiflenebilir hub, satıcının platformun daha da fazla izlenebilirliği ve taşınabilirliğine yönelik yönünü ortaya koyuyor. Otomasyonunuz için varsayılanlara daha az bağımlılık, kriptografik olarak daha doğrulanabilir kaynak kanıtları ve makine tarafından okunabilir meta veriler. SDP 26.7'de yapılan tüm değişikliklerin tam bir özetini sürüm notlarında bulabilirsiniz.

(harita)