Kubernetes Ağ Politikaları ile Mikro Segmentasyon: Adım Adım Uygulama Kılavuzu

Kubernetes ağ politikaları, pod'lar arası ve pod'lardan dış dünyaya giden trafiği denetleyen kaynaklardır. Bu politikalarla mikro segmentasyon uygulayarak, saldırı yüzeyini daraltabilir ve güvenlik ihlallerinin yanal yayılmasını engelleyebilirsiniz. Bu kılavuzda, network policy'lerin nasıl çalıştığını, temel bileşenlerini ve adım adım uygulama örneklerini bulacaksınız.

Kubernetes Network Policy Nedir ve Neden Kullanmalısınız?

Kubernetes cluster'ında varsayılan olarak tüm pod'lar birbiriyle iletişim kurabilir. Bu, esneklik sağlasa da güvenlik açısından risk oluşturur. Network Policy, belirli pod'ların hangi pod'larla veya IP aralıklarıyla iletişim kurabileceğini tanımlayan bir Kubernetes kaynağıdır. Bu sayede, örneğin bir web sunucusu pod'unun yalnızca veritabanı pod'una erişmesine izin verip diğer pod'larla iletişimini engelleyerek mikro segmentasyon elde edersiniz. Mikro segmentasyon, sıfır güven (zero trust) mimarisinin temel taşlarından biridir.

Temel Bileşenler: Pod Seçiciler, Giriş ve Çıkış Kuralları

Bir Network Policy tanımı üç ana bileşenden oluşur:

• Pod Seçici (podSelector): Politikanın hangi pod'lara uygulanacağını belirler. Etiketler (labels) kullanılarak pod'lar seçilir.
• Giriş Kuralları (ingress): Seçilen pod'lara gelen trafiğe izin veren kurallar. Kaynak pod'lar veya IP blokları belirtilir.
• Çıkış Kuralları (egress): Seçilen pod'lardan giden trafiğe izin veren kurallar. Hedef pod'lar veya IP blokları belirtilir.

Bir policy'de hem ingress hem de egress kuralları tanımlanabilir. Boş bırakılan bir kural, ilgili yöndeki tüm trafiği engeller (varsayılan olarak trafiğe izin verilmez).

Mikro Segmentasyon Nasıl Sağlanır?

Mikro segmentasyon, uygulama katmanları arasındaki trafiği kısıtlayarak her bir hizmetin yalnızca ihtiyaç duyduğu iletişim kanallarına sahip olmasını sağlar. Örneğin, bir e-ticaret uygulamasında frontend pod'ları yalnızca backend pod'larına, backend pod'ları ise yalnızca veritabanı pod'larına erişebilir. Bu yaklaşım, bir pod'un ele geçirilmesi durumunda saldırganın diğer pod'lara yatay hareketini sınırlar. CSPM ve CWPP araçları bu tür politikaların uyumluluğunu izlemede yardımcı olabilir.

Adım Adım: Basit Bir Network Policy Oluşturma

1. Pod etiketlerini belirleyin: Örneğin, frontend pod'larına app: frontend, backend pod'larına app: backend etiketi atayın.
2. Network Policy manifest dosyası oluşturun: Aşağıdaki gibi bir YAML dosyası hazırlayın. Bu policy, frontend pod'larına yalnızca backend pod'larından gelen trafiğe izin verir ve frontend pod'larının yalnızca backend pod'larına çıkış yapmasına izin verir.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: frontend-policy
spec:
  podSelector:
    matchLabels:
      app: frontend
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: backend

3. Policy'yi uygulayın: kubectl apply -f frontend-policy.yaml komutu ile politikayı cluster'a gönderin.
4. Doğrulama yapın: kubectl describe networkpolicy frontend-policy ile politikayı kontrol edin. İzin verilmeyen bir trafiği test etmek için geçici bir pod oluşturup bağlantı deneyebilirsiniz.

Sık Yapılan Hatalar ve Dikkat Edilmesi Gerekenler

• Varsayılan izin verilmez (default deny) kuralını unutmak: Network Policy tanımlanmamış pod'lar hala tüm trafiğe izin verir. Tüm pod'lar için varsayılan bir deny policy oluşturmak iyi bir uygulamadır.
• Egress kurallarını ihmal etmek: Yalnızca ingress kuralları tanımlamak, dışarıya çıkan trafiği denetlemez. Saldırganın veri sızdırmasını önlemek için egress kuralları da kritiktir.
• IP bloklarını doğru kullanmamak: IP blokları kullanırken except alanıyla istisnalar belirtmeyi unutmayın.
• Network Plugin desteğini kontrol etmemek: Tüm CNI eklentileri (Calico, Cilium, Weave vb.) Network Policy'yi destekler; ancak kullandığınız eklentinin özelliklerini doğrulayın. Örneğin, Calico daha gelişmiş özellikler sunar.

Gerçek Dünya Senaryoları ve En İyi Uygulamalar

Bir mikro hizmet mimarisinde her hizmet için ayrı ayrı policy tanımlamak yerine, namespace bazında politikalar gruplandırılabilir. Örneğin, bir namespace içindeki tüm pod'lar arası iletişimi kısıtlayan bir policy oluşturup alt kümelerde daha spesifik kurallar ekleyebilirsiniz. Ayrıca, Kubernetes RBAC ile birlikte kullanarak, hem ağ hem de API düzeyinde erişim kontrolü sağlanabilir. Birden fazla cluster kullanıyorsanız, multi-cloud stratejileri ile politikaların tutarlılığını korumak için araçlar (örneğin, Calico Enterprise) kullanabilirsiniz.

Network Policy'leri test etmek için kubectl run ile geçici pod'lar kullanabilir, hızlıca doğrulama yapabilirsiniz. Güvenlik ihlali durumunda olay müdahale planınızı devreye alarak politikaları güncelleyebilirsiniz.

Network Policy'lerin yönetimi ölçeklenebilirlik açısından zor olabilir. Bu nedenle, Policy as Code yaklaşımı benimseyerek politikaları Git ile versiyonlayın ve otomasyon araçlarıyla (ArgoCD, Flux) dağıtın. Ayrıca, düzenli olarak audit log'larını inceleyerek politikaların etkinliğini doğrulayın.

Sık Sorulan Sorular

Kubernetes network policy tüm CNI eklentilerinde çalışır mı?

Hayır, network policy desteği CNI eklentisine bağlıdır. Calico, Cilium, Weave Net ve Antrea gibi eklentiler desteklerken, Flannel temel olarak desteklemez. Kullanmadan önce eklentinizin dokümantasyonunu kontrol edin.

Bir pod için birden fazla network policy tanımlanırsa ne olur?

Kubernetes, aynı pod için tanımlanan tüm network policy'lerin birleşimini uygular. Yani, herhangi bir policy izin veriyorsa trafiğe izin verilir (union mantığı). Bu nedenle, çakışan kurallar dikkatlice yönetilmelidir.

Network Policy'lerden sonra trafik neden hala çalışıyor?

Bu durum, kullandığınız CNI eklentisinin network policy'yi desteklememesi veya policy'nin doğru şekilde uygulanmamış olmasından kaynaklanabilir. Ayrıca, varsayılan olarak tüm trafiğe izin verildiğini unutmayın; policy yalnızca belirtilen pod'ları etkiler.