Applied Kubernetes Hardening: A Practical Playbook
Kubernetes kümelerini sağlamlaştırma konusunda pratik bir rehber; RBAC, pod güvenliği, ağ politikaları ve tedarik zinciri kontrollerini kapsamaktadır.
Kubernetes, varsayılan olarak esneklik ile birlikte gönderilir, güvenlik değil. Her açık port, izin verici RBAC rolü ve kısıtlanmamış pod bir davettir. Bir kümeyi sağlamlaştırmak, ona bağlı olan iş yüklerini bozmadan bu boşlukları sistematik olarak kapatmak anlamına gelir. Bu bir kontrol listesi alıştırması değildir—kimlik, ağ, iş yükü ve tedarik zinciri katmanlarına dokunan devam eden bir disiplindir.
Kontrol Düzlemini Önce Kilitle
API sunucusu herhangi bir kümedeki en değerli tek hedefidir. Anonim kimlik doğrulamayı devre dışı bırakarak ve güçlü kimlik doğrulama yöntemlerini uygulayarak başlayın—kimlik sağlayıcınızla OIDC entegrasyonu, hiç sona ermeyecek statik tokenlere veya istemci sertifikalarına tercih edilir. etcd veri deposuna erişimi kısıtlayın, çünkü şifreleme bekleme durumunda etkinleştirilmediği sürece her sırrı ve yapılandırma nesnesini düz metin olarak tutar. KMS sağlayıcısını kullanarak sırlar için şifrelemeyi etkinleştirin; hiçbir gerçek koruma sağlayan base64 kodlamasına güvenmeyin. Denetim günlüğü ilk günden itibaren açık olmalıdır; olmadan, bir şey ters gittiğinde hiçbir adli kanıt izine sahip değilsiniz.
RBAC: Kolaylık Değil, En Az Ayrıcalık
Üretim kümelerinde en yaygın yanlış yapılandırma, çok geniş RBAC bağlamalarıdır—tek bir ad alanında podları okumaya ihtiyaç duyan hizmet hesaplarına verilmiş cluster-admin. Roller gerçek iş işlevleri etrafında oluşturun ve bunları mümkün olduğunca ad alanlarına kapsamlı hale getirin. Role ve ClusterRole tanımlarında joker karakter fiilleri ve kaynakları önleyin. Bağlamaları kubectl auth can-i --list veya rbac-lookup gibi araçlarla düzenli olarak denetleyin ve ayrıcalık sürüşünü yakalayın. Hizmet hesapları insan kullanıcılarla aynı titizlikle incelenmeyi hak eder—API erişimine ihtiyaç duymayan podlar için hizmet hesabı tokenleri otomatik montajını devre dışı bırakın.
Pod Güvenliği: Tehlikenin Mümkün Olduğunu Varsayın
Pod Security Admission (kullanımdan kaldırılan PodSecurityPolicy yerini alan) temel veya kısıtlı profilleri ad alanı düzeyinde uygulamanızı sağlar. En az olarak, ayrıcalıklı kapsayıcıları, ana bilgisayar ad alanı paylaşımını ve ayrıcalık yükseltmesini yasaklayın. runAsNonRoot: true ayarlayın ve varsayılan olarak tüm Linux yeteneklerini bırakın, yalnızca açıkça gerekli olanları geri ekleyin. Salt okunur kök dosya sistemleri saldırganların çalışan bir kapsayıcıya kötü amaçlı ikili dosyalar yazmasını engeller. Bu denetimler önemlidir çünkü bir kapsayıcı kaçışı veya istismar edilen uygulama açığı tam düğüm uzlaşmasına dönüşmemelidir.
Ağ Politikaları İsteğe Bağlı Değildir
Varsayılan olarak, bir Kubernetes kümesindeki her pod diğer her podu ile konuşabilir. Bu düz ağ modeli saldırganlar için yan hareket rüyasıdır. NetworkPolicy kaynaklarını uygulamak için varsayılan reddedilmiş giriş ve çıkışı uygulayın, sonra açıkça yalnızca uygulamalarınızın gerektirdiği trafik akışlarına izin verin. Bu, NetworkPolicy uygulamayı gerçekten destekleyen bir CNI eklentisi gerektirir—Calico, Cilium ve diğerleri bu rolü doldurur çünkü temel Kubernetes ağ modeli kendisi hiçbir şeyi uygulamaz. Ad alanlarını güven sınırına göre bölümlemek ve üzerine politika katmanlamak gerçek derinlemesine savunma sağlar.
Resim ve Tedarik Zinciri Bütünlüğü
Sağlamlaştırma çalışma zamanı yapılandırmasında durmaz—ne dağıttığınızla başlar. Kapsayıcı görüntülerini kayıt defterinize ulaşmadan önce bilinen açıklıklar açısından tarayın ve Kyverno veya OPA Gatekeeper gibi giriş kontrolörleri kullanarak yalnızca imzalanmış, doğrulanmış görüntülerin kümenizde çalışmasını sağlayın. Görüntü etiketlerini değişken etiketler yerine sinir yerine sabitle; örneğin latest altında sessizce değişebilir. Podların çekmeye izin verilen kayıt defterlerini kısıtlayın, güvenliği ihlal edilmiş veya yazım hatası yapılmış görüntülerin üretime kaydığı yaygın bir tedarik zinciri saldırısı yolunu kapatın.
Kubernetes Varsayılanlarının Ötesinde Sırlar Yönetimi
Kubernetes Secrets doğal olanı hiçbir şeyden iyidir, ancak gerçek bir sırlar yönetim çözümü değildir. Harici bir sırlar yöneticisini entegre etmeyi düşünün—Vault, AWS Secrets Manager veya benzer—ve sırları küme nesneleri olarak depolamak yerine çalışma zamanında enjekte edin. Doğal Secrets kullanmanız gerekiyorsa, etcd şifrelemesinin etkinleştirildiğinden ve RBAC'ın okuma erişimini sıkıca kısıtladığından emin olun, çünkü bir ad alanındaki sırlara get izni olan herhangi bir pod veya kullanıcı kimlik bilgilerini sızıntıya uğratabilir.
Tek Seferlik Kurulum Değil, Sürekli Doğrulama
Sağlamlaştırma yapılandırmaları zaman içinde kayıyor çünkü yeni iş yükleri dağıtılıyor ve öncelikler güvenlikten hıza doğru kaymaya başlıyor. kube-bench gibi araçlar CIS Kubernetes Benchmark'a karşı uyumluluğu kontrol ederken, kube-hunter kümenize karşı saldırgan keşfini simüle edebilir. Bu kontrolleri CI/CD boru hatlarına dahil edin; böylece yanlış yapılandırmalar bir olaydan yanıt çağrısı sırasında yerine üretime ulaşmadan yakalanır.
Kubernetes sağlamlaştırması, tek bir çoban çözüğü kontrolü hakkında daha az ve kimlik, ağ, iş yükü ve tedarik zinciri genelinde katmanlama savunmaları hakkında daha fazladır—böylece bir katmandaki arıza tam uzlaşmaya dönüşmez. Bulut altyapısı güvenlik desenleri ve savunma araçları hakkında daha fazla bilgi için Korra Studio'nun DEFENSE_GRID platformundaki ilgili segmentleri keşfedin.
AI yardımıyla yazıldı, Michal Pilch (CISSP), Korra Studio tarafından incelendi ve yayınlandı.
Bu, Korra Studio bilgi tabanından bir nottur — platform her konuyu 1-to-1 mentoring ile eşleştirir.
Ücretsiz başlaarrow_forward