Kubernetes ve mikro hizmet tabanlı uygulama mimarilerinin tüm avantajlarından yararlanmak için kuruluşların güvenliği nasıl uyguladıklarını değiştirmeleri gerekir. Bu dönüşüm, genellikle geliştirme ve operasyon ekipleri ve süreçleri arasındaki boşlukları ve siloları ortaya çıkarır. Örnek olay: geliştiriciler ve ağ güvenlik ekibi arasındaki boşluk.
300’den fazla DevOps, mühendislik ve güvenlik uzmanının anket sonuçlarına göre, “2022 Kubernetes Durumu Güvenlik Raporu” (PDF), güvenliğin kapsayıcı ve Kubernetes’in benimsenmesiyle ilgili en büyük endişelerden biri olduğunu gösteriyor ve katılımcılar, güvenlik sorunlarının uygulamaların üretime dağıtımında gecikmelere neden olduğunu belirtiyor.
Ankete katılanların neredeyse tamamı, %93’ü, son 12 ayda Kubernetes ortamlarında en az bir güvenlik olayı yaşadıklarını ve %31’i bir güvenlik olayı nedeniyle bir gelir veya müşteri kaybı rapor ettiğini söyledi.
Bu olayların çoğu insan hatasından kaynaklanıyor ve yanıt verenlerin yarısından fazlası (%53) son 12 ayda Kubernetes’te bir yanlış yapılandırma tespit ettiklerini söylüyor. Kubernetes’in yanlış yapılandırmalarından kaçınmak için birçok en iyi uygulama vardır, ancak gerçek şu ki Kubernetes büyüktür ve belirli bir miktarda karmaşıklığı vardır. Roller, sorumluluklar ve beceri grupları arasındaki boşluklar – özellikle eski uygulamaları yeniden düzenleyen şirketler için yaygın – kapıyı güvenlik açıklarına açık bırakıyor.
Örneğin, geliştiriciler ve ağ güvenlik ekibi, çapraz amaçlarla değilse de silolarda çalışıyor olabilir. Geçmişte, geliştiriciler ağ güvenliğini uygulayanlar olmadılar – sadece uygulamaları duvardan aşağı atarlar ve ağ yapılandırmasıyla ilgilenmek için güvenlik ekibine güvenirlerdi.
Ancak Kubernetes dünyasında güvenlik yükü DevOps’tadır – veya en azından algı bu. Ve insanların şöyle düşünmesi mantıklı: “Sola kayma” kavramının tamamı, güvenliğin geliştirme döngüsünün mümkün olduğu kadar erken ele alınmasıdır.
Gerçekten de ankete göre, kapsayıcıların ve Kubernetes’in güvenliğini sağlamaktan sorumlu olarak en sık belirtilen rol DevOps’tur: Ankete katılanların %15’i geliştiricileri Kubernetes güvenliğinin birincil sahipleri olarak görürken, yalnızca %18’i güvenlik ekiplerini en sorumlu olarak tanımlar.
Ancak, özellikle sıfırıncı gün istismarları nispeten yaygın bir olay olduğunda, sola kaydırmak yeterli değildir. Yalnızca geliştirme, BT operasyonları ve ağ ve diğer güvenlik ekipleri arasında sıkı bir işbirliği, uygulamaları saldırganlara, özellikle de öldürme zinciri boyunca olabildiğince uzağa hareket edebilecekleri giriş noktaları arayanlara karşı makul ölçüde güvenli hale getirebilir.
Kuruluşlar muhtemelen tüm bunları teoride anlıyorlar, ancak gerçekte, ağ güvenliği ve Kubernetes söz konusu olduğunda kimsenin umurunda olmayan bir alan var: Küme içindeki ağ yapılandırmasını kim yönetiyor, anlıyor ve gözden geçiriyor? Yanlış yapılandırmaları kim tespit ediyor ve düzeltiyor?
Şirketler sıfır güven modeline doğru ilerledikçe geliştiriciler ve ağ güvenliği ekibi arasındaki boşluk daha da büyüyebilir. Sıfır güvenle, elbette hiçbir şeye güvenilmez. Ancak işletmeler bu şekilde yürüyemez. Bir noktada, birinin birbirleriyle iletişim kurmak için belirli uygulamalara ve hizmetlere izin vermesi gerekir.
Kubernetes’in NetSec İkilemi
Varsayılan olarak Kubernetes dağıtımları, Kubernetes bölmelerine ağ ilkesi uygulamaz. Ağ ilkeleri olmadan, herhangi bir pod diğer herhangi bir pod veya ağ uç noktasıyla konuşabilir; bu, güvenlik duvarı olmayan bir bilgisayara eşdeğerdir. Birisi içeri girmeli ve pod iletişimini tanımlanmış varlıklarla sınırlayan giriş ve çıkış ağ ilkelerini tanımlamalıdır.
Geçmişte, geliştiriciler hangi iletişim yollarının kullanılabilir hale getirilmesi gerektiğini belirttiler ve ağ yöneticileri bu yolları geleneksel güvenlik duvarı yapılandırmaları aracılığıyla kullanılabilir hale getirdi.
Sorun, ağ güvenliği mühendislerinin Kubernetes dilini konuşmamasıdır. Kube dünyasında, ağ güvenliğiyle ilgili yaptığınız her şeyin bir veri serileştirme dili olan YAML’de yazılması gerekir, ancak ağ güvenliği mühendisleri IP adresleri ve IP tabloları açısından düşünür. NetSec ekibi, ilkelerin yazıldığı dili gerçekten anlamıyor ve araçlar onlara aşina değil.
Ağ güvenliğini ve diğer boşlukları köprüleyen araçlardan biri, kuruluşlara araçlar, eğitim ve Kubernetes kümelerini izlemek ve bu kümelerde çalışan iş yükleri.
Ağ yapılandırması söz konusu olduğunda StackRox, geliştiricilerin ve güvenlik ekiplerinin mevcut ve izin verilen ağ trafiğini görselleştirmesine olanak tanır. NetSec ekipleri, Kubernetes’e özgü kontrolleri kullanarak ağ politikalarını ve daha sıkı segmentasyonu daha etkin bir şekilde uygulayabilir. StackRox yakın zamanda geliştiricilerin uygulamalarını Kubernetes’e dağıtmadan önce ağ ilkelerini tanımlamalarına yardımcı olacak yeni bir özellik ekledi. Bu, geliştiricilerle ortaklaşa geliştirildi. np koruma projesi. StackRox roxctl artık kaynak YAML’lerini analiz ederek ağ ilkeleri oluşturmak için np-guard’ı çağırma seçeneğine sahiptir.
StackRox projesiyle kuruluşlar, tüm uygulama yaşam döngüsü boyunca tüm önemli güvenlik kullanım durumlarını ele alabilir. Yukarıda bahsettiklerime uygun olarak StackRox, uygulamalar için ağ izolasyonu ve erişim kontrollerini uygulama ve yönetme sürecini kolaylaştırıyor. Diğer kullanım durumları şunları içerir:
Güvenlik açığı yönetimi: StackRox, görüntülerdeki ve kapsayıcıları çalıştıran güvenlik açıklarını belirleyerek kuruluşların bilinen güvenlik açıklarına karşı korunmasına yardımcı olur.
Güvenlik yapılandırma yönetimi: Kuruluşlar, Kubernetes’in en iyi güvenlik uygulamalarına göre yapılandırıldığından emin olmak için StackRox’tan yararlanabilir.
Risk profili oluşturma: StackRox, dağıtımlarla ilgili çeşitli verileri analiz ederek Kubernetes kümeleri genelinde güvenlik sorunlarına öncelik vermek için gereken bağlamı sağlar.
Uyma: Kuruluşlar, sözleşme ve mevzuat gerekliliklerini karşılamak için StackRox’un uyumluluk politikalarından yararlanabilir.
Algılama ve yanıt: StackRox, olaylara müdahale yetenekleri sağlayarak kuruluşların ortamlarındaki aktif tehditleri ele almasına olanak tanır.
Genel olarak, StackRox gibi Kubernetes’e özgü kontrolleri kullanmak – başka bir deyişle, uygulama geliştirme ve güvenlik için aynı altyapıyı ve kontrollerini kullanmak – şirketlerin güvenliği sola kaydırmaktan 360 derecelik bir döngüye kaydırmasına olanak tanır ve tüm bunları genişletirken Kubernetes’in otomasyon ve ölçeklenebilirlik avantajları.
İndirebilirsin GitHub’dan StackRox burada. Burada, geliştiricilerin Kubernetes YAML dosyalarını kolayca kontrol etmelerini sağlayan bir statik analiz aracı olan KubeLinter ve yanlış yapılandırmaları tespit etmek ve en iyi güvenlik uygulamalarını uygulamak için Helm çizelgeleri gibi ilgili projeleri de bulacaksınız.