Bugün kuruluşların Kubernetes kullanıp kullanmadıkları değil, kullanımlarını nasıl genişlettikleri önemli. Örneğin, birden fazla kümenin kullanımı artıyor ve organizasyon sınırlarını aşıyor. Kubernetes’in kendisi destekleniyor Ortaya çıkan güvenlik sorunlarını karşılayın. En yeni sürüm olan Kubernetes 1.26, diğer güvenlik güncellemelerinin yanı sıra güven zincirini güçlendirmek için tasarlanmış özellikler ekler. Aslında, kuruluşların daha güçlü güvenlik, gözlemlenebilirlik, yönetişim ve uyumluluk oluştururken Kubernetes kullanımlarını optimize ettiklerinden emin olmak için izlemesi ve potansiyel olarak değerlendirmesi gereken birkaç proje var.
SPIFFE ve SPIRE
Her şey için kimlik, Kubernetes ortamınızı korumanın önemli bir parçasıdır, ancak uçtan uca kimlik, özellikle çok kümeli Kubernetes ortamlarında hâlâ çözülmemiş bir sorundur. Kubernetes’te bir hizmetiniz olduğunu ve bulutta veya şirket içinde çalışan küme dışı bir hizmette kimlik doğrulaması yapmanız gerektiğini varsayalım. Hizmetin başlatılmasından küme içinde ve dışında iletişim kurduğu ve bağlandığı her şeye kadar güvenli bir kimlik zincirine sahip olduğunuzdan nasıl emin olabilirsiniz?
bu SPIFFE projesi heterojen ortamlarda ve kuruluş sınırlarında iş yüklerinde yazılım sistemlerini güvenli bir şekilde tanımlamaya yönelik bir dizi açık kaynak standardıdır. Herkes için Güvenli Üretim Kimliği Çerçevesi (SPIFFE), kısa ömürlü kriptografik kimlik belgelerini veya Gölge Sanal Saldırı Tespit Sistemi (SVIDS), iş yüklerinin diğer iş yüklerinde kimlik doğrulaması yapmak için kullanabileceği. SPIFFE’nin kimlik ortağı KULEVİ, SPIFFE çalışma zamanı ortamı. SPIRE, kimlikleri vermek için çok faktörlü doğrulamayı zorunlu kılan SPIFFE spesifikasyonunu uygular. Hâlâ yapılacak işler olsa da, her ikisi de Bulut Yerel Bilgi İşlem Vakfı (CNCF) tarafından geliştirilen SPIFFE ve SPIRE projeleri, yalnızca uçtan uca kimlik için değil, aynı zamanda sıfır güven için de temel oluşturmaya yardımcı oluyor.
Mağaza
Bir zincirin ancak en zayıf halkası kadar güçlü olduğu şeklindeki eski atasözü, en zayıf halkası söz konusu olduğunda olduğundan daha doğru olamaz. yazılım tedarik zinciri. Son birkaç yıldır gördüğümüz tedarik zinciri saldırılarının gösterdiği gibi – risk arttıkça artması muhtemel saldırılar – tedarik zincirinde hiçbir şeyin kurcalanmadığından emin olmak giderek daha önemli hale geliyor. Bunu yapmanın yollarından biri, özellikle her şeyi (hatta çoğu şeyi) kod olarak yapıyorsanız, her şeyi imzalamaktır.
Sigstore – Linux Vakfı’nın himayesinde – tedarik zincirinde kriptografik imzalamayı kolaylaştırmayı amaçlamaktadır. Sigstore, geliştiricilerin kriptografi yükünü kaldırarak kodlarını imzalamak için önceden var olan bir tanımlayıcı olarak OpenID Connect (OIDC) protokolü aracılığıyla bir e-posta adresi kullanmalarını sağlar. Kuruluşların Sigstore’u daha geleneksel yöntemlerle uyguladığını görüyoruz, ancak imzalamayı yönetmenin daha çevik bir yolu olarak OIDC tabanlı imzalamayı (Sigstore projesinin Fulcio kısmı aracılığıyla) ve Rekor imza günlüğünü benimseyip benimsemediklerini görmek ilginç olacak. imzaların tasdiki veya imzaların doğrulanması. Sigstore’un sonunda sadece yeni ürünlerde değil, aynı zamanda kuruluşun kendi içinde de uygulanıp uygulanmayacağını görmek ilginç olacak.
Kyverno ve OPA Bekçisi
KyvernoKubernetes yerel politika yönetimi sağlayan , izlenmesi gereken bir projedir çünkü kuruluşlar, özellikle Kubernetes topluluğu pod güvenlik kabulüne doğru ilerlerken, kabul politikalarına daha fazla dikkat etmektedir. Tasarım gereği basit bir model olan Kubernetes’e özgü pod güvenlik kabulüyle ilişkili yalnızca üç profil vardır. Daha fazla karmaşıklık istiyorsanız, bunun gibi bir şeyle gitmeniz gerekir. bekçi ve Açık Politika Aracısı (OPA). Bazı kuruluşlar, Kyverno’nun Kubernetes ile kullanımını daha kolay bulmaktadır. YAML tabanlı olduğundan yeni bir dil öğrenmeyi gerektirmez. Bununla birlikte, OPA yığın boyunca ilkeleri otomatikleştirmek için kullanılabilen genel amaçlı bir ilke motoru olduğundan, diğer kuruluşlar Open Policy Agent ile kullanılan dil olan Rego’yu öğrenmeye yatırım yaptı. Aslında, şu anda kullanılabilen çeşitli açık kaynak politika motorları var. Asıl soru, manzaranın Kubernetes ile değişen derecelerde entegrasyona sahip motorlarla noktalı olmaya devam edip etmeyeceği veya sonunda birinin fiili standart haline gelip gelmeyeceğidir.
eBPF Tabanlı Projeler
Kubernet’ler ve birlikte çalıştığı teknolojiler, büyük ölçüde temel Linux yeteneklerine dayanır. Bunlardan biri Genişletilmiş Berkeley Paket Filtresi(Ağ oluşturma, güvenlik ve denetim ile izleme ve izleme araçlarında giderek daha fazla kullanılan eBPF). Daha da önemlisi, çalışma zamanı güvenliği söz konusu olduğunda, eBPF derin bir düzeyde gözlemlenebilirlik sağlar. Göremediğiniz şeyi güvence altına alamazsınız ve eBPF, Kubernetes ve konteyner platformları için ihtiyaç duyduğunuz gözlemlenebilirlik düzeyini daha tüketilebilir bir şekilde sağlar. eBPF, aşağıdakiler de dahil olmak üzere birçok proje tarafından kullanılmaktadır: falcobir Kubernetes çalıştırma zamanı güvenlik aracı ve kirpik, kapsayıcı iş yükleri arasında ağ bağlantısı sağlayan, güvenliğini sağlayan ve gözlemleyen. Hangi projelerin zirveye çıkacağının en büyük göstergesi, Kubernetes ile ne kadar iyi oynadıklarıdır. Örneğin, Cilium ilginçtir çünkü C yerine Go ile yazılmıştır, bu da Kubernetes’e entegrasyonu kolaylaştırır.
Kubernetes Ağ Projeleri
Giderek daha fazla kuruluşun birden çok küme dağıttığını ve bunun sonucunda kümeler arasında iletişim kuran veya etkileşim kuran çözümlere ihtiyaç duyulduğunu görüyoruz. Kepçe ilginç çünkü kuruluşların bir veya daha fazla Kube kümesindeki ad alanlarından bir tür sanal uygulama ağı oluşturmasını sağlıyor. Kümeler arasındaki iletişimi yönetmek için VPN’lere veya özel güvenlik duvarı kurallarına olan ihtiyacı ortadan kaldıran yepyeni bir yaklaşımdır. bu Ağ Geçidi API’si. Gateway API, tarafından yönetilen açık kaynaklı bir projedir. SIG Ağı toplum.
Çözüm
Kuruluşlar Kubernetes kullanımlarını genişlettikçe, performans kazanımlarını güvenlik, yönetişim ve uyumlulukla dengeleme konusunda sürekli tetikte olmalıdırlar.