giriiş Kubernetes lider konteyner düzenleme platformu olarak olgunlaşmaya devam ederken, konteynerli uygulamaları dağıtan kuruluşlar için güvenlik en önemli endişe kaynağı olmaya devam ediyor. Kubernetes'in güvenlik cephaneliğindeki temel araçlar arasında bir zamanlar çok önemli bir rol oynuyordu. PSP, yöneticilerin Pod'lar üzerindeki güvenlik kısıtlamalarını titizlikle tanımlamasına ve uygulamasına olanak tanıyarak yalnızca belirli güvenlik standartlarını karşılayan konteynerlerin küme içinde çalışabilmesini sağladı. Ancak Kubernetes güvenliğinin kapsamı hızla gelişiyor ve Kubernetes 1.25'ten başlayarak PSP'nin artık kullanımdan kaldırıldığını belirtmek önemlidir (Kubernetes 1.25 Acil Sürüm notları bağlantısına bakın). Bu değişiklik, PSP politikalarını yönetme ve sürdürmenin karmaşıklığı da dahil olmak üzere çeşitli faktörlerden kaynaklanıyor ve çoğu zaman kullanıcılar için operasyonel zorluklara yol açıyor. Kullanımdan kaldırmaya yanıt olarak kuruluşlar artık PSP'ye yalnızca güvenlik gereksinimlerini karşılamakla kalmayıp aynı zamanda iş yüklerini güvence altına alma sürecini de kolaylaştıran modern alternatifler arıyor. Bu kapsamlı kılavuzda, Pod Güvenlik Girişine (PSA) geçişe odaklanarak Kubernetes güvenlik uygulamalarındaki bu değişimi yönlendirmek için bir yolculuğa çıkıyoruz. PSA mevcut en sağlam alternatiflerden biridir ve bu makale onu derinlemesine inceliyor. Ancak diğer iki alternatif olan Kyverno ve OPA Gatekeeper'ın bu seride ayrı yazılarda ele alınacağını da belirtmekte fayda var. Bu makale boyunca PSA'nın kurulumu ve kurulumuyla ilgili ayrıntılı talimatlar, PSP'den PSA'ya sorunsuz geçiş için adım adım geçiş kılavuzları ve mevcut PSP kurallarını PSA'ya aktarmak için kesin komutlar bulacaksınız. Ek olarak, PSA'ya uyarlanmış prova komutlarını kullanarak ad alanlarının geçişe hazır olup olmadığını değerlendirme bilgisini de edineceksiniz. Bu kılavuzun sonunda PSA'nın güçlü yönleri ve sınırlamaları hakkında kapsamlı bir anlayışa sahip olacak ve kuruluşunuzun özel güvenlik gereksinimlerine ve Kubernetes ortamına göre bilinçli bir karar vermenizi sağlayacak donanıma sahip olacaksınız. Bu kılavuzla Kubernetes güvenlik uygulamalarınızı güvenle modernleştirerek Pod Güvenlik Politikaları çağına veda ederken iş yüklerinizin korunmaya devam etmesini sağlayabilirsiniz. Pod Güvenlik Politikaları (PSP) Kubernetes'teki Pod Güvenlik Girişi (PSA) PSA, konteynerlerin Pod Güvenlik Standartları tarafından tanımlanan Kubernetes'in yerel güvenlik standartlarına uymasını sağlar. Bu standartlar, güvenlik politikalarını her biri farklı düzeyde kısıtlayıcılığa sahip üç farklı profile göre sınıflandırır: PSA, Kubernetes Güvenlik Standartlarını Zorluyor: : Ayrıcalıklı politika kasıtlı olarak açıktır ve tamamen sınırsızdır. Bu politika genellikle güvenilir kullanıcılar tarafından yönetilen sistem ve altyapı düzeyindeki iş yüklerini hedefler. Kısıtlamaların olmaması ile karakterize edilir. Gatekeeper gibi varsayılan olarak izin verme mekanizmaları doğası gereği Ayrıcalıklı olabilirken, Pod Güvenlik Politikası (PSP) gibi varsayılan olarak reddetme mekanizmaları için Ayrıcalıklı politikanın tüm kısıtlamaları devre dışı bırakması gerekir. Ayrıcalıklı : Baseline ilkesi, bilinen ayrıcalık yükseltmelerini önlerken yaygın kapsayıcılı iş yükleri tarafından kolayca benimsenecek şekilde tasarlanmıştır. Uygulama operatörlerine ve kritik olmayan uygulamaların geliştiricilerine hitap eder. Baseline : Kısıtlı politikası, bazı uyumlulukların potansiyel olarak pahasına olmasına rağmen, Pod sağlamlaştırma konusunda sıkı en iyi uygulamaları uygulamaya odaklanır. Öncelikle güvenlik açısından kritik uygulamaların operatörleri ve geliştiricilerinin yanı sıra daha az güvenilen kullanıcıları hedefler. Her profilde uygulanması veya izin verilmemesi gereken kontrollerin kapsamlı bir listesi için resmi belgelere başvurabilirsiniz. Kısıtlı Diğer bazı çözümlerden farklı olarak PSA, Pod Güvenlik Politikası (PSP) kurallarını doğrudan taşımak veya değiştirmek için basit bir yöntem sunmaz. PSA'nın öncelikli odak noktası, yukarıda bahsedilen profiller de dahil olmak üzere, pod'ların yerleşik göre doğrulanmasıdır. Doğrudan PSP Kural Aktarımı Yok: Kubernetes güvenlik standartlarına : PSA doğrulamada etkili olsa da, PSP'nin yapabildiği gibi kapsül özelliklerini değiştiremez veya özelleştiremez. PSA'nın ana amacı, önceden tanımlanmış Kubernetes güvenlik standartlarını uygulamaktır ve pod özelliklerini değiştirmeye veya değiştirmeye yönelik özellikler içermez. Öncelikle kapsüllerin bu belirlenmiş standartlara göre doğrulanmasına odaklanır. Mutasyon Yok Kurulum ve Kurulum PSA bir Kubernetes Yerel bileşeni olduğundan, çalışmasını sağlamak için Kubernetes kümenizde Pod Güvenlik Girişi (PSA) denetleyicisinin etkinleştirildiğinden emin olmanız yeterlidir. Bunu aşağıdaki komutu çalıştırarak yapabilirsiniz: kubectl api-versions | grep admission Geçiş için Hazırlık Adımları Ad Alanı İzinlerini Değerlendirin Pod Güvenliği Girişinin kontrolü ad alanı etiketlerinden etkilenir. Bu, ad alanlarını güncelleme, düzeltme eki uygulama veya oluşturma becerisine sahip kişilerin aynı zamanda bu ad alanlarına ilişkin Pod Güvenliği ayarlarını değiştirme yetkisine de sahip olduğu anlamına gelir. Bu değişiklik potansiyel olarak daha katı güvenlik politikalarını atlayabilir. Devam etmeden önce ad alanı izinlerinin yalnızca güvenilen ve ayrıcalıklı kullanıcılara atandığını doğrulamak önemlidir. Bu tür erişime ihtiyaç duymayan kullanıcılara bu yükseltilmiş izinleri vermekten kaçınmanız önerilir. Ad Alanı nesnelerinde Pod Güvenliği etiketlerini yapılandırmak için ek kısıtlamalara ihtiyaç duyulursa bu kısıtlamaları uygulamak için bir kabul web kancası kullanmayı düşünün. PodSecurityPolicy'leri Kolaylaştırın ve Normalleştirin Pod Güvenlik Girişine (PSA) geçmeden önce PodSecurityPolicies'inizi (PSP) normalleştirmeniz faydalı olacaktır: : Pod Güvenlik Standartları kapsamında olmayan seçenekleri ortadan kaldırın. Bu seçenekler şunları içerir: Desteklenmeyen Alanları Kaldır .spec.allowedHostPaths .spec.allowedFlexVolumes .spec.allowedCSIDrivers .spec.forbiddenSysctls .spec.runtimeClass : Yalnızca mutasyona neden olan ve doğrulama politikasını etkilemeyen alanları kaldırarak süreci başlatın. "PodSecurityPolicies'i Pod Güvenlik Standartlarıyla Eşleştirme" referansında da belirtildiği gibi bu alanlar şunları içerir: Tamamen Mutasyona Uğrayan Alanları Ortadan Kaldırın .spec.defaultAllowPrivilegeEscalation .spec.runtimeClass.defaultRuntimeClassName .metadata.annotations['seccomp.security.alpha.kubernetes.io/defaultProfileName'] .metadata.annotations['apparmor.security.beta.kubernetes.io/defaultProfileName'] .spec.defaultAddCapabilities Önemli Not: Bu alanların kaldırılması, gerekli yapılandırmaların eksik olduğu iş yüklerine yol açabilir ve bu da potansiyel olarak operasyonel sorunlara neden olabilir. Basitleştirilmiş politikalarla iş yüklerinin doğru şekilde çalışabilmesini sağlamak büyük önem taşıyor. Uygun Pod Güvenlik Düzeyini Belirleyin Ad alanınız için uygun Pod Güvenliği düzeyini belirlerken dikkate almanız gereken birkaç yöntem vardır: Ad Alanının Güvenlik Gereksinimlerine Göre Ad alanı için beklenen erişim düzeyine ve güvenlik gereksinimlerine aşinaysanız bu özel gereksinimlere göre uygun bir Kapsül Güvenlik düzeyi seçebilirsiniz. Bu yaklaşım, yeni bir kümedeki güvenlik ayarlarına nasıl yaklaşacağınıza benzer. Mevcut PodSecurityPolicy'lere göre: Mevcut Pod Güvenlik Politikalarınızın (PSP'ler) her birini karşılık gelen referansını kullanın. PSP'leriniz başlangıçta Pod Güvenlik Standartlarını temel almıyorsa bir karar vermeniz gerekebilir. En az PSP'leriniz kadar izin veren bir Pod Güvenlik düzeyi seçin veya en az PSP'leriniz kadar kısıtlayıcı bir düzey seçin. Belirli bir ad alanındaki bölmeler için hangi PSP'lerin kullanıldığını belirlemek için aşağıdaki komutu kullanın: Pod Güvenlik Standardı düzeyiyle eşlemek için "Pod Güvenlik Politikalarını Pod Güvenlik Standartlarıyla Eşleştirme" kubectl get pods -n $NAMESPACE -o jsonpath="{.items[*].metadata.annotations.kubernetes\.io\/psp}" | tr " " "\n" | sort -u Mevcut Kapsüllere Göre: Bir prova gerçekleştirin ve hem Temel hem de Kısıtlı Kapsül Güvenliği seviyelerini test etmek için sonraki bölümdeki etiket komutunu uygulayın. Bu, bu düzeylerin mevcut iş yükleriniz için yeterince izin verici olup olmadığını değerlendirmenize yardımcı olur. Mevcut iş yüklerinizle uyumlu, en az ayrıcalıklı geçerli düzeyi seçin. Bahsedilen seçeneklerin mevcut bölmeleri temel aldığını ve bu bölmelerin, o anda çalışmayan iş yüklerini hesaba katmayabileceğini unutmamak önemlidir. Buna CronJob'lar, sıfıra ölçeklendirme iş yükleri veya henüz dağıtılmamış diğer iş yükleri dahildir. Pod Güvenlik Düzeyini Test Etme Ad alanınız için Pod Güvenlik düzeyini belirledikten sonra (Ayrıcalıklı düzey hariç), seçilen politikayı doğrulamanız önemlidir. Pod Security, sorunsuz bir kullanıma sunma ve güvenlik standartlarıyla uyumluluk sağlamak için test seçenekleri sunar. Kuru Çalışma Testi: Seçilen politikanın etkisini anında yürürlüğe koymadan değerlendirmek için bu yöntemi kullanın. Prova yapmak için belirtilen ilke düzeyini karşılamayan mevcut bölmeleri vurgulayacak aşağıdaki komutu kullanın: kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/enforce=$LEVEL Denetim Modu Testi: Denetim modu, politika ihlallerini uygulamadan kaydetmenize olanak tanır. İhlal eden bölmeler daha sonra incelenmek üzere denetim kayıtlarına kaydedilir. Denetim modunu şu komutla etkinleştirin: kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/audit=$LEVEL Test sırasında beklenmedik politika ihlalleri ortaya çıkarsa şunları yapabilirsiniz: Uyumlu olmayan iş yüklerini politikayla uyumlu olacak şekilde güncelleyin. İş yükü gereksinimlerinizi karşılamak için gerekiyorsa ad alanının Pod Güvenliği düzeyini ayarlayın. Pod Güvenlik Düzeyini Zorunlu Hale Getirme Seçilen Pod Güvenlik düzeyinin ad alanınız için uygun olduğundan emin olduktan sonra bunu uygulamaya devam edebilirsiniz. Bu adım, istenen güvenlik standartlarının ad alanı içindeki iş yüklerinize aktif olarak uygulanmasını sağlar. Ad alanında istenen Pod Güvenliği düzeyini uygulamak için aşağıdaki komutu kullanın: kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/enforce=$LEVEL Bu komutun yürütülmesi, belirtilen Pod Güvenlik düzeyini etkinleştirip uygulayacak ve ad alanınızın güvenlik durumunu geliştirecektir. PSP'yi atlamak PodSecurityPolicy'yi ad alanı düzeyinde etkili bir şekilde atlamak için ad alanındaki tüm hizmet hesaplarına tam ayrıcalıklı bir Pod Güvenlik Politikası'nı (PSP) bağlayabilirsiniz. Bu süreç, ad alanı içindeki bölmelerin artık PodSecurityPolicy tarafından uygulanan değişikliklere veya kısıtlamalara tabi tutulmamasını sağlar. Bunu küme düzeyinde veya bireysel ad alanı düzeyinde yapabilirsiniz. Küme Kapsamlı Kurulum (Kümenin tamamı için Yalnızca Bir Kez Gerekir): gibi bir YAML yapılandırma dosyası uygulayarak tam ayrıcalıklı bir Pod Güvenlik Politikası (PSP) oluşturun. Bu PSP, bölmelere gerekli tüm ayrıcalıkları vermeli ve Pod Güvenlik Politikalarının (PSP'ler) kullanımına izin vermek ve bunu ayrıcalıklı PSP ile ilişkilendirmek için ayrıcalıklı-psp adında bir küme rolü oluşturmalıdır: ayrıcalıklı-psp.yaml kubectl apply -f privileged-psp.yaml kubectl create clusterrole privileged-psp --verb use --resource podsecuritypolicies.policy --resource-name privileged Ad Alanı Başına Devre Dışı Bırakma: Ayrıcalıklı psp kümesi rolünü grubuyla ilişkilendirmek için hedef ad alanında bir rol bağlama oluşturun. Bu bağlama, PodSecurityPolicy'yi atlayarak, ad alanı içindeki tüm hizmet hesaplarının tam ayrıcalıklı PSP'ye etkin bir şekilde erişmesine izin verir: system:serviceaccounts:$NAMESPACE kubectl create -n $NAMESPACE rolebinding disable-psp --clusterrole privileged-psp --group system:serviceaccounts:$NAMESPACE Bu kurulumla ayrıcalıklı PSP mutasyona uğramaz ve PodSecurityPolicy giriş denetleyicisi her zaman mutasyona uğramayan PSP'lere öncelik verir. Sonuç olarak, bu ad alanındaki bölmeler artık PodSecurityPolicy tarafından değiştirilmeyecek veya kısıtlanmayacak. Bu yaklaşımın bir avantajı tersine çevrilebilirliğidir. Herhangi bir sorun ortaya çıkarsa PodSecurityPolicy'nin devre dışı bırakılmasıyla ilişkili RoleBinding'i silerek değişikliği kolayca geri alabilirsiniz. Bu süreç boyunca önceden var olan Kapsül Güvenlik Politikalarının yürürlükte kaldığından emin olun. PodSecurityPolicy'yi Devre Dışı Bırakmayı Geri Al: Ad alanı için PodSecurityPolicy devre dışı bırakma işlemini geri almak için daha önce oluşturulan RoleBinding'i silmeniz yeterlidir: kubectl delete -n $NAMESPACE rolebinding disable-psp Ad Alanı Oluşturma Süreçlerini Yeniden Ziyaret Edin Mevcut ad alanlarının Kapsül Güvenliği Girişini zorunlu kılmak için güncellenmesi nedeniyle, yeni ad alanları oluşturmaya yönelik süreçlerinizi ve politikalarınızı gözden geçirip güncellemeniz çok önemlidir. Bu, yeni ad alanlarının en başından itibaren uygun bir Pod Güvenliği profiliyle yapılandırılmasını sağlar. Ad alanı oluşturma süreçlerini geliştirmek için aşağıdaki adımları göz önünde bulundurun: : İstediğiniz Pod Güvenlik düzeyinin seçimini ve uygulamasını içerecek şekilde kuruluşunuzun yeni ad alanları oluşturmaya yönelik politikalarını ve prosedürlerini güncelleyin. Güvenlik standartlarının oluşturma aşamasından itibaren oluşturulduğundan emin olun. Ad Alanı Oluşturma İlkelerini Ayarlayın Etiketlenmemiş ad alanları için varsayılan uygulama, denetim ve/veya uyarı düzeylerini tanımlamak üzere Pod Güvenliği giriş denetleyicisini statik olarak yapılandırabilirsiniz. Bu yaklaşım, açık Pod Güvenliği etiketlerine sahip olmayan ad alanlarının varsayılan olarak belirlediğiniz güvenlik standartlarına uymaya devam etmesini sağlar. Statik Yapılandırma: Ad alanı oluşturma süreçlerinizi yeniden gözden geçirerek Pod Güvenliği standartlarını sorunsuz bir şekilde entegre edebilir ve eski ve yeni tüm ad alanlarında tutarlı ve güvenli bir yaklaşım sürdürebilirsiniz. Kubernetes ortamınıza PodSecurityPolicy'yi devre dışı bırakın PodSecurityPolicy (PSP) giriş denetleyicisine artık ihtiyaç duyulmadığından ve Pod Güvenlik Girişi'nin (PSA) başarıyla uygulanıp doğrulandığından emin olduğunuzda, PSP giriş denetleyicisini devre dışı bırakmaya devam edebilirsiniz. PSP giriş denetleyicisini devre dışı bırakma adımları şunlardır: Kube-apiserver Yapılandırmasını değiştirin: Genellikle /etc/kubernetes/manifests/kube-apiserver.yaml. PSP giriş denetleyicisini devre dışı bırakmak için bayrağını ekleyin. Aktif giriş eklentileri listesinden kaldırıldığından emin olun. --disable-admission-plugins kube-apiserver --disable-admission-plugins=PodSecurityPolicy Yapılandırma dosyasını kaydedin. Kube-apiserver'ı yeniden başlatın: Değişiklikleri uygulamak için kube-apiserver'ı yeniden başlatın. Bunu genellikle Kubernetes kontrol düzlemini veya kube-apserver bölmesinin kendisini yeniden başlatarak başarabilirsiniz. systemctl restart kubelet Doğrulama: Kube-apserver günlüklerini veya durumunu kontrol ederek PSP giriş denetleyicisinin devre dışı bırakıldığından emin olun. PSP'lere geri dönmeniz gerekmeyeceğinden emin olmak için yeterli "ıslanma süresi" sonrasında bir sonraki adıma geçin. PSP Kaynaklarını Temizleme: PSP giriş denetleyicisi devre dışı bırakıldığında ve PSA yerindeyken, mevcut PodSecurityPolicies'inizin yanı sıra ilgili Rolleri, ClusterRoles'u, RoleBinding'leri ve ClusterRoleBinding'leri güvenli bir şekilde silebilirsiniz. kubectl delete podsecuritypolicies --all kubectl delete roles,clusterroles,rolebindings,clusterrolebindings --selector=rbac.authorization.kubernetes.io/autoupdate=true Bu temizleme adımı, kümenizde artık PSP yapılandırması kalmamasını sağlar. PSP giriş denetleyicisini devre dışı bırakarak ve PSP ile ilgili kaynakları ortadan kaldırarak kümenizin güvenlik mimarisini basitleştirir ve Pod Güvenlik Girişine geçişi tamamlarsınız. Özet Bu kapsamlı kılavuzda Pod Güvenlik Politikalarından (PSP) Pod Güvenlik Girişine (PSA) sorunsuz bir şekilde geçirmek için gerekli adımları ve dikkat edilmesi gereken noktaları inceledik. Bu geçiş, iş yüklerinizin güvenli bir şekilde çalışmaya devam etmesini ve aynı zamanda Kubernetes'in gelişen güvenlik standartlarıyla uyumlu olmasını sağlar. Kubernetes kümenizin güvenlik çerçevesini Pod Güvenlik Girişini (PSA) Kullanmanın Artıları ve Eksileri Artıları: : PSA, Kubernetes'in ayrılmaz bir parçasıdır ve üçüncü taraf araç kurulumlarına olan ihtiyacı ortadan kaldırır. Platformun yerleşik güvenlik özelliklerinden yararlanır. Yerel Kubernetes Bileşeni : PSA, Kubernetes'in yerel güvenlik standartlarıyla uyumlu hale gelerek platformun en iyi uygulamalarıyla uyumluluğu sağlar. Kubernetes Standartlarını Zorlar Eksileri: : PSA, özellikle bölme özelliklerinin değiştirilmesini gerektiren karmaşık güvenlik politikaları için, PSP ile aynı düzeyde özelleştirme sağlamayabilir. Sınırlı Özelleştirme : Mevcut iş yükleri, YAML dosyalarının değiştirilmesini gerektirebilecek güvenlik bağlamı ayarlarını içerecek şekilde güncellenmelidir. Güçlendirme Gerekli Bu kılavuz, sizi PSP'den PSA'ya güvenle geçiş yapmak için gereken bilgi ve adımlarla donatarak Kubernetes iş yüklerinizi korurken güvenli ve verimli bir geçiş sağlar. Kyverno ve OPA Gatekeeper'a alternatif geçiş yollarını keşfedeceğim gelecek makaleler için bizi takip etmeye devam edin.

This story contains new, firsthand information uncovered by the writer.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Bu ses hikayenin orijinal dilinde üretilmiştir!

Pod Güvenlik Politikalarından Geçiş: Kapsamlı Bir Kılavuz (Bölüm 1: PSA'ya Geçiş)

Çok uzun; Okumak

@viachaslaumatsukevich

Credibility

İLGİLİ ÖYKÜLER