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

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 Pod Güvenlik Politikaları (PSP) 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 Kubernetes'teki 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 Girişi (PSA)

• PSA, Kubernetes Güvenlik Standartlarını Zorluyor: 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:

  
  

  • Ayrıcalıklı : 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.

  • Baseline : 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.

  • Kısıtlı : 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.

    
    

• Doğrudan PSP Kural Aktarımı Yok: 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 Kubernetes güvenlik standartlarına göre doğrulanmasıdır.

• Mutasyon Yok : 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.

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:

• Desteklenmeyen Alanları Kaldır : Pod Güvenlik Standartları kapsamında olmayan seçenekleri ortadan kaldırın. Bu seçenekler şunları içerir:

  
  

 .spec.allowedHostPaths .spec.allowedFlexVolumes .spec.allowedCSIDrivers .spec.forbiddenSysctls .spec.runtimeClass

• Tamamen Mutasyona Uğrayan Alanları Ortadan Kaldırın : 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:

 .spec.defaultAllowPrivilegeEscalation .spec.runtimeClass.defaultRuntimeClassName .metadata.annotations['seccomp.security.alpha.kubernetes.io/defaultProfileName'] .metadata.annotations['apparmor.security.beta.kubernetes.io/defaultProfileName'] .spec.defaultAddCapabilities

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 Pod Güvenlik Standardı düzeyiyle eşlemek için "Pod Güvenlik Politikalarını Pod Güvenlik Standartlarıyla Eşleştirme" 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:

 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.

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):

ayrıcalıklı-psp.yaml 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:

 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ü system:serviceaccounts:$NAMESPACE 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:

 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:

1. Ad Alanı Oluşturma İlkelerini Ayarlayın : İ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.

2. Statik Yapılandırma: 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.

   
   

   Ad alanı oluşturma süreçlerinizi yeniden gözden geçirerek Pod Güvenliği standartlarını Kubernetes ortamınıza sorunsuz bir şekilde entegre edebilir ve eski ve yeni tüm ad alanlarında tutarlı ve güvenli bir yaklaşım sürdürebilirsiniz.

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 --disable-admission-plugins bayrağını ekleyin. Aktif giriş eklentileri listesinden kaldırıldığından emin olun.

 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 Kubernetes kümenizin güvenlik çerçevesini 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.

Pod Güvenlik Girişini (PSA) Kullanmanın Artıları ve Eksileri

Artıları:

• Yerel Kubernetes Bileşeni : 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.
• Kubernetes Standartlarını Zorlar : PSA, Kubernetes'in yerel güvenlik standartlarıyla uyumlu hale gelerek platformun en iyi uygulamalarıyla uyumluluğu sağlar.

Eksileri:

• Sınırlı Özelleştirme : 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.
• Güçlendirme Gerekli : Mevcut iş yükleri, YAML dosyalarının değiştirilmesini gerektirebilecek güvenlik bağlamı ayarlarını içerecek şekilde güncellenmelidir.

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.