Kubernetes ortamlarında microservices tabanlı mimariler hızla yaygınlaşıyor. Mikro servisler arasındaki trafiği doğru şekilde yönetmek ve güvenlik kural setlerini uygulamak ise her geçen gün daha kritik hâle geliyor. Bu noktada devreye giren Kubernetes Network Policy, hem ağ izolasyonunu sağlar hem de servisler arasındaki erişimleri ince ayarlarla yönetmenize olanak tanır. Bu yazıda, Network Policy kavramlarını derinlemesine inceleyecek, Zero-Trust modeline uyumlu politika tasarımını ele alacak, ayrıca yaygın kullanım senaryoları ve konfigurasyon hatalarına dair uygulamalı örnekler paylaşacağız.

1. Network Policy Nedir, Neden Önemlidir?

Network Policy’ye Giriş

  • Network Policy, Kubernetes içindeki Pod’ların birbiriyle ve dış dünya ile olan trafiğini kontrol eden kurallardır.
  • Pod’ların hangi IP adreslerine ve hangi port’lara erişebileceği, hangi protokollere izin verileceği bu politikalarla belirlenir.
  • Klasik güvenlik yaklaşımı, ağ sınırını (DMZ vb.) koruma üzerine kurulu iken, Zero-Trust felsefesi ağ içindeki her noktayı potansiyel bir risk olarak görür. Bu nedenle her Pod’un minimum yetki ile izole edilmesi hedeflenir.

Neden Önemli?

  • Saldırı yüzeyini küçültür: Belirli Pod’ların gereksiz servislere veya dış kaynaklara erişimini engelleyerek olası saldırıları sınırlarsınız.
  • Microservices mimarisini sağlamlaştırır: Servislerin kendi aralarındaki iletişimi daha ince detaylarda kontrol edebilirsiniz.
  • Yönetilebilirlik: Ağ politikalarını sürükle-bırak veya GUI araçlarından yönetmek yerine, versiyonlanabilir YAML dosyaları aracılığıyla kod olarak yönetirsiniz (Infrastructure as Code).

2. Zero-Trust Modeline Uygun Network Policy Tasarımı

Zero-Trust yaklaşımının temel ilkesi, “default deny” (varsayılan olarak her şeyi engelle, izin verilmesi gerekeni aç) prensibine dayanır. Kubernetes Network Policy ile bu prensibi hayata geçirmek oldukça kolaydır.

Temel İlkeler

  1. Varsayılan Engelleme: Namespace veya Pod düzeyinde, hiçbir Pod’a dışarıdan trafik gelmesine izin verme.
  2. Minimum Gerekli Erişim: Sadece belirlenen Pod’lar, belirlenen port’lar, belirlenen namespace’ler ve protokoller üzerinden haberleşebilsin.
  3. Uygulamaya Özel Politika: Her mikro servis için ayrı bir Network Policy tanımlayarak, gereksiz bağlantıları kapatın.

Örnek YAML Konfigürasyonu

Aşağıdaki örnek, frontend isimli bir Pod/label grubuna sadece backend isimli label grubundan gelen trafiğe izin verir. Ayrıca bu trafiğin TCP 80 ve 443 portları üzerinden gerçekleşmesini şart koşar.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend-to-frontend
  namespace: my-namespace
spec:
  podSelector:
    matchLabels:
      app: frontend
  policyTypes:
  - Ingress
  ingress:
    - from:
      - podSelector:
          matchLabels:
            app: backend
      ports:
        - protocol: TCP
          port: 80
        - protocol: TCP
          port: 443
  • podSelector: Hangi Pod’ların bu politika kapsamına gireceğini tanımlar (burada app=frontend).
  • policyTypes: Gelen trafiği (Ingress) veya giden trafiği (Egress) kontrol edebileceğinizi belirtir.
  • ingress.from: İzin verilen kaynakları tanımlar (burada app=backend).
  • ports: Hangi port/protokollere izin verileceği.

Bu yapı, Zero-Trust prensibine uygun olarak, belirli servisler arasındaki trafiği açıkça tanımlarken, diğer tüm trafiği otomatik olarak engeller.

3. İleri Düzey Network Policy Örnekleri

Multi-Tenant Senaryoları

Birden fazla ekibin veya projenin aynı Kubernetes cluster’ını paylaştığı durumlarda, her tenant (kiracı) kendi namespace’inde çalışır. Network Policy ile namespace’ler arası erişimi tamamen engelleyebilir veya sınırlı tutabilirsiniz.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: multi-tenant-isolation
  namespace: team-a
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            team: a
  egress:
    - to:
      - namespaceSelector:
          matchLabels:
            team: a
  • Burada team: a label’ına sahip namespace dışındaki tüm giriş ve çıkış trafiğini engellemiş oluyoruz.
  • podSelector: {} ifadesi, bu network policy’nin namespace içindeki tüm Pod’ları kapsamasını sağlar.

Namespace İzolasyonu

Bazen tek bir tenant olsa bile, geliştirme, test ve üretim (dev, test, prod) ortamlarını aynı cluster’da barındırmanız gerekebilir. Bu durumda, yanlışlıkla dev ortamından prod veritabanına erişilmesini engellemek istersiniz:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: dev-isolation
  namespace: dev
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
    - to:
      - namespaceSelector:
          matchLabels:
            environment: dev
  • Sadece environment=dev etiketine sahip namespace’e veri çıkışı yapmasına izin verir.
  • Böylece dev namespace’indeki uygulamalar, prod namespace’ine erişemez.

4. Uygulamalı Troubleshooting: Hata Tespiti ve Çözüm Teknikleri

Kubernetes Network Policy ile uğraşırken sıkça yapılan konfigürasyon hatalarına ve bunların çözüm yollarına bir göz atalım.

4.1. “NetworkPolicy Uyguladım, Tüm Trafik Kesildi!”

Nedeni: Her Network Policy, yazılı olduğu namespace içindeki Pod’lara varsayılan olarak önce her şeyi engellemez. Fakat, bir Pod’a Ingress veya Egress tipinde herhangi bir Network Policy tanımlarsanız, o Pod için bahsi geçen trafik (gelen ya da giden) “izin verilmeyen her şeyi” engelleyebilir hale gelir.

Çözüm: Eğer amacınız belirli bir trafik türünü bloklamak değil, sadece ek bir politikayla belli bağlantıları kısıtlamaksa, en azından temel seviye bir allow all politikası eklemeniz gerekebilir. Örneğin:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-egress
  namespace: my-namespace
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
    - {}

Bu politika, TÜM Pod’lar için her türlü dış trafiğe izin verir. Ardından kısıtlamak istediğiniz durumlar için ek bir politika tanımlayabilirsiniz. “0’dan kapama” stratejisi güdüyorsanız, tam tersi şekilde, “hepsini kapat” ve sadece izin vermek istediklerinizi açma yöntemini izlemelisiniz.

4.2. Network Policy’nin Çalışmadığını Fark Ettim

Nedeni: Çoğu zaman, CNI (Container Network Interface) eklentiniz Network Policy’yi desteklemiyor olabilir. Mesela bazı basit CNI’lar sadece temel ağ yönlendirmesi yapar fakat Network Policy kurallarını uygulamaz.

Çözüm:

  1. kubectl describe pod <pod-ismi> komutuyla, kullanılan CNI plugini (Weave, Calico, Cilium vb.) gözlemleyin.
  2. Kullandığınız eklentinin NetworkPolicy kaynaklarını desteklediğinden emin olun. (Örneğin, Calico Network Policy desteğini varsayılan olarak sunar.)

4.3. Yaml Dosyasındaki “podSelector”, “namespaceSelector”, “ipBlock” Tanımları Arasında Karışıklık

Nedeni: Bazen aynı anda birden fazla selector (örneğin hem podSelector hem namespaceSelector) kullanmak istersiniz ancak YAML yanlış dizilimde olur.

Çözüm: Her bir from veya to kuralında, doğru şekilde nested (iç içe) yapı kullanmaya özen gösterin. Örneğin:

ingress:
  - from:
    - podSelector:
        matchLabels:
          app: myapp
    - namespaceSelector:
        matchLabels:
          environment: prod
    - ipBlock:
        cidr: 10.0.0.0/24

Aynı kural seti içinde bir list olarak tanımlandığında hepsi geçerli olur ve “OR” mantığıyla çalışır (yani ya app: myapp ya environment: prod ya da 10.0.0.0/24 bloğu ise izin ver).

5. Best Practice’ler ve Sonuç

Best Practice Önerileri

  1. Varsayılan “deny all” politikası ekleyerek başlayın ve yalnızca gerçekten ihtiyaç duyulan trafiği “allow” (izin ver) kuralı ile açın.
  2. Granüler Tanımlar: Pod düzeyinde (örneğin app=payment gibi) spesifik label’lar kullanın. Daha büyük ölçekte hem karmaşıklığı azaltır hem de yönetilebilirliği arttırır.
  3. Versiyon Kontrolü: YAML dosyalarınızı Git gibi bir versiyonlama sistemi üzerinde tutun. Değişiklikleri inceleyip geri almanız daha kolay olacaktır.
  4. Belgeleme: Her network policy kuralına, neyi koruduğunu ve hangi senaryoyu adreslediğini belirten açıklamalar ekleyin.
  5. Sürekli İzleme: Aktif Network Policy’leri periyodik olarak gözden geçirin. Yeni microservice eklendiğinde veya konfigürasyon değiştiğinde, politika kurallarınızı güncellemeyi unutmayın.

Sonuç

Kubernetes Network Policy, Zero-Trust yaklaşımının Kubernetes ortamlarda vücut bulmuş hâlidir. Her Pod’u potansiyel bir risk kaynağı olarak görüp, erişim izinlerini en düşük seviyede başlatarak (minimum yetki ilkesi) sisteminizi çok daha güvenli bir hâle getirebilirsiniz.

Bu rehberde, temel network policy yapı taşlarından başlayarak ileri düzey konulara, multi-tenant senaryolarına ve troubleshooting örneklerine değindik. Unutmayın, doğru uygulanan Network Policy stratejisi, microservices altyapınızın hem yönetilebilirliğini hem de güvenliğini önemli ölçüde artıracaktır.

Kaynaklar & İleri Okuma

Sorularınızı veya yorumlarınızı aşağıda paylaşabilirsiniz!