GKE ClusterNetworkPolicy, public preview aşamasında küme geneli ve katmanlı ağ koruma bariyerleri sunuyor

GKE için küme kapsamlı bir policy

Google Kubernetes Engine, halihazırda Public Preview aşamasında olan, küme kapsamlı yeni bir network policy kaynağı olan ClusterNetworkPolicy'yi kullanıma sundu. dev.to'da yayımlanan bir Google Cloud yazısına göre, platform ve güvenlik ekiplerinin bir kümedeki tüm namespace'lere yayılan ve namespace düzeyindeki policy'lerin geçersiz kılamayacağı trafik kuralları tanımlamasına olanak tanıyor.

Çözdüğü sorun

Standart Kubernetes NetworkPolicy nesneleri tek bir namespace ile sınırlıdır ve birden fazla policy aynı pod'u seçtiğinde etkileri birikimlidir: trafiğe izin veren tek bir policy varsa trafik kabul edilir. Yazıya göre bu model, tek bir uygulama içindeki microservice'leri izole etmek için işe yarar, ancak küme yöneticilerine küme geneli koruma bariyerleri için yerleşik bir mekanizma bırakmaz. Her pod'un cloud metadata sunucusuna erişimini engellemek veya bir namespace'i diğerlerinden tamamen izole etmek için şimdiye kadar karmaşık policy motorları, özel admission controller'lar veya namespace kapsamlı policy'ler enjekte eden otomasyonlar gerekiyordu; yazı bu yaklaşımları kırılgan ve denetlenmesi zor olarak nitelendiriyor.

Üç katmanlı bir değerlendirme zinciri

Birikimli namespace modelinin aksine, ClusterNetworkPolicy, ilk eşleşen kuralın kazandığı katı ve sıralı bir zincir halinde değerlendirilir. Traffic üç katmandan sırayla geçer:

• Admin katmanı: ilk olarak değerlendirilir. Yöneticilerin geliştiricilerin aşamayacağı zorunlu kuralları koyduğu yer burasıdır ve eşleşen bir Accept veya Deny kararı değerlendirmeyi anında durdurur.
• NetworkPolicy katmanı: Admin katmanında karara bağlanmayan trafik, geliştiricilerin ve DevOps ekiplerinin yapılandırdığı sıradan namespace kapsamlı NetworkPolicy kaynaklarına göre kontrol edilir.
• Baseline katmanı: hiçbir namespace policy'sinin eşleşmediği trafik için yedek kurallar; örneğin geliştiricilerin kendi namespace'lerinde geçersiz kılmayı seçebileceği küme geneli bir varsayılan-deny (default-deny) duruşu.

Bir paket hiçbir katmandaki hiçbir kuralla eşleşmezse, GKE varsayılan davranışına geri dönerek pakete örtük olarak izin verir. Her katmanın içinde policy'ler 0 ile 1000 arasında sayısal bir önceliğe göre sıralanır; düşük sayılar önceliklidir ve tek bir policy içindeki kurallar yukarıdan aşağıya değerlendirilir.

Pass dahil üç karar türü

Her kural üç eylemden birini taşır. Deny trafiği engeller, Accept izin verir ve ikisi de zinciri kısa devre yapar. Pass ise kararı bir sonraki katmana devreder. Yazı, Pass'ı temel devir mekanizması olarak vurguluyor: bir yönetici belirli bir akışla — örneğin 8080 portundaki web trafiğiyle — eşleşebilir, Admin katmanındaki kalan kuralları atlayabilir ve kararı namespace sahibine bırakabilir. Bir namespace policy'si trafiği kabul ederse trafik akar; böyle bir policy yoksa değerlendirme Baseline katmanına devam eder. Yazıya göre bu, merkezi uyumluluk ile geliştirici çevikliği arasında denge kurar.

Örnek policy'lerin gösterdiği

Tasarımı iki desen ortaya koyuyor. İlki, Admin katmanına yerleştirilen ve sensitive-ns etiketli bir namespace'i seçerek diğer tüm namespace'lere giden ve gelen tüm ingress ve egress trafiğini reddeden küresel bir deny kuralı; hiçbir geliştirici policy'sinin gevşetemeyeceği bir sınır. İkincisi, tüm namespace'leri kapsayan Baseline katmanındaki bir default-deny kuralı. Bir frontend servisine harici bir ingress controller'dan ingress gerektiren geliştirici, standart bir namespace kapsamlı NetworkPolicy dağıtmak yeterlidir; NetworkPolicy katmanı Baseline katmanından önce çalıştığı için trafik platform yöneticisinin müdahalesi olmadan izinli hale gelir.

Gereksinimler ve sınırlar

Uygulama tamamen açık kaynak Cilium üzerine inşa edilmiştir. Google bu desteği GKE kümeleri için Cilium 1.19'a geri taşıdı (backport) ve yukarı akıştaki (upstream) yeteneğin Cilium 1.20 ile başlayarak daha geniş açık kaynak ekosisteminde genel kullanıma açılması bekleniyor. Kümeler GKE sürüm 1.36.0-gke.4447000 veya daha yenisini çalıştırmalı ve Dataplane V2 kullanmalıdır. Bir preview özelliği olarak, tek bir ClusterNetworkPolicy nesnesi 100 ingress ve 100 egress kuralıyla sınırlıdır ve trafik kararları GKE Dataplane V2 gözlemlenebilirlik araçlarıyla izlenip sorun giderilebilir.

Neden önemli

ClusterNetworkPolicy, küme geneli koruma bariyerlerini namespace düzeyindeki yapılandırmadan ayırarak güvenlik ekiplerlerine daha önce kırılgan otomasyonlardan derlemek zorunda kaldıkları bir dayatma gücü veriyor. Pass eylemiyle birlikte katmanlı model, uyumluluk kuralları ile geliştirici esnekliğinin artık rekabet etmediği anlamına geliyor: yöneticiler sert sınırlar veya makul varsayılanlar koyarken ekipler kendi namespace'leri üzerindeki günlük kontrolü elinde tutuyor. Cilium temeli ayrıca, bu hiyerarşik policy modelinin Cilium 1.20'de upstream'e girdiğinde GKE'nin ötesine giderek daha geniş Kubernetes ekosistemine yayılabileceğine işaret ediyor; bu da Google Cloud'da olmayan ekipler için bile anlaşılmasını değerli kılıyor. Bugün değerlendirecek olan herkes bunu belirtilen kural sınırları ve sürüm gereksinimlerini akılda tutarak bir preview olarak ele almalı.