CNI Network Policies

Varsayılan (default) bir Kubernetes kurulumunda, cluster içindeki tüm pod'lar birbiriyle hiçbir kısıtlama olmadan özgürce konuşabilir. Bu durumu, yüzlerce insanın bulunduğu ve herkesin herkesle fısıldaşabildiği devasa bir salona benzetebiliriz. Ancak iş production ortamına geldiğinde, uygulamanızın güvenliği için bu iletişimi sıkı kurallara bağlamanız gerekir.

İşte tam bu noktada Network Policies devreye girer. Ancak standart Kubernetes yetenekleri bazen yetersiz kalabilir. Bu yazıda, standart politikaların ötesine geçen CNI tabanlı gelişmiş ağ politikalarını, özellikle de modern altyapıların favorisi olan Cilium üzerinden A'dan Z'ye inceleyeceğiz.

1. Temel Kavramlar: Ingress, Egress ve Whitelist Modeli

Network politikalarını anlamak için trafik yönlerini ve güvenlik duruşunu netleştirmemiz gerekir:

Ingress (Geliş): Bir pod'a dışarıdan gelen trafiktir.
Egress (Çıkış): Bir pod'dan dışarıya başlatılan trafiktir.

🛡️ Default Deny ve Whitelist

Güvenlikte en iyi pratik "Default Deny" duruşudur. Bir network politikası uyguladığınız an, Kubernetes o pod için "Whitelist" modeline geçer. Yani: Açıkça izin verilmeyen her türlü trafik anında bloklanır (drop).

       [ İzin Verilmeyen Pod ] ──(❌ DROP)─┐
                                           │
  [ Frontend Pod ] ──(✅ İZİN VERİLDİ)──▶ [ Hedef Pod (Backend) ] ──(✅ İZİN VERİLDİ)──▶ [ Database Pod ]
                                           ▲ (Ingress Kontrolü)          (Egress Kontrolü) ▼
                                           │                                               │
       [ Dış Dünya (İnternet) ] ──(❌ DROP)┘                                   (❌ DROP) [ Başka Sunucu ]

2. Standart Kubernetes Politikaları vs. CNI Uzantıları

Kubernetes kendi içinde temel bir ağ politikası desteği sunar (sadece IP ve Port bazlı). Ancak Cilium veya Calico gibi gelişmiş bir CNI eklentisi kullandığınızda, sisteminize adeta "süper güçler" eklemiş olursunuz.

Özellik

Standart (Built-In) Policy

CNI Eklentileri (Örn: Cilium)

Layer 7 Filtreleme

✖️ Yok

✅ HTTP, gRPC, Kafka bazlı derin kurallar

Şifreleme & İzolasyon

✖️ Yok

✅ mTLS ve IPsec desteği

Gelişmiş Kısıtlamalar

✖️ Yok

✅ IP Whitelist/Blacklist, Rate Limiting

Gözlemlenebilirlik

Kısıtlı

✅ Gerçek zamanlı metrikler ve anlık trafik izleme

Çoklu Cluster (Multi-Cluster)

✖️ Yok

✅ Birden fazla cluster'ı kapsayan global kurallar

Neden Cilium?

Cilium, Linux çekirdeğindeki eBPF teknolojisini kullanır. Bu sayede paketleri pod'a gelmeden çok daha önce, çekirdek (kernel) seviyesinde inanılmaz bir hızla analiz eder ve filtreler. Performans kaybı yaratmadan Layer 3'ten Layer 7'ye kadar derinlemesine güvenlik sağlar.

3. Katman Katman Ağ Politikaları (Layer 3, Layer 4, Layer 7)

Cilium ile ağ politikaları (CiliumNetworkPolicy) yazarken kurallarınızı OSI modelinin farklı katmanlarına göre belirleyebilirsiniz. Her politikanın kalbinde, kuralın hangi pod'lara uygulanacağını belirten endpointSelector bulunur.

🌐 Layer 3 (Ağ Katmanı) Politikaları

Bu katman, derin paket incelemesi (Deep Packet Inspection) yapmadan, sadece IP adreslerine, label'lara (etiketlere) veya DNS isimlerine bakarak trafiğe yön verir.

Örnek 1: Sadece belirli pod'lardan gelen Ingress trafiğine izin vermek:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: layer3-ingress-only
spec:
  endpointSelector:
    matchLabels:
      role: backend
  ingress:
    - fromEndpoints:
        - matchLabels:
            role: frontend

(Bu kural: Sadece role: frontend etiketli pod'ların, role: backend etiketli pod'lara erişmesine izin verir.)

Örnek 2: Belirli IP bloklarına (CIDR) Egress çıkışına izin vermek:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: layer3-egress-cidr
spec:
  endpointSelector:
    matchLabels:
      role: backend
  egress:
    - toCIDR:
        - "20.1.1.1/32"
    - toCIDRSet:
        - cidr: "10.0.0.0/8"
          except:
            - "10.96.0.0/12"

Bu kural, backend pod'larının dışarıya (egress) sadece 20.1.1.1 IP'sine ve 10.0.0.0/8 ana ağına veri göndermesine izin verir.

Ancak except komutuyla bir istisna koyarak, izin verilen bu geniş ağın içindeki 10.96.0.0/12 bloğuna erişmelerini kesinlikle engeller.

🚪 Layer 4 (Taşıma Katmanı) Politikaları

Bu katman TCP ve UDP portlarını kontrol eder. Cilium varsayılan olarak ping (ICMP) isteklerini bloklar.

Örnek 3: Dışarıya sadece TCP 80 portundan çıkışa izin vermek:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: layer4-example
spec:
  endpointSelector:
    matchLabels:
      app: myService
  egress:
    - toPorts:
        - ports:
            - port: "80"
              protocol: TCP

🧠 Layer 7 (Uygulama Katmanı) Politikaları

Standart Kubernetes politikalarının yapamadığı sihir buradadır. Sadece IP ve Porta bakmaz; paketin içine girerek HTTP metodunu (GET, POST), URL yollarını (path) veya HTTP başlıklarını (headers) okuyup karar verir.

Örnek 4: HTTP Path ve Header bazlı ince ayar güvenlik:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: layer7-example
spec:
  endpointSelector:
    matchLabels:
      app: myService
  ingress:
    - toPorts:
        - ports:
            - port: "80"
              protocol: TCP
      rules:
        http:
          - method: GET
            path: "/path1$"
          - method: PUT
            path: "/path2$"
            headers:
              - "X-My-Header: true"

(Bu mükemmel kural şunları söyler: myService pod'una 80 portundan gelen bir istek eğer GET /path1 ise kabul et. Eğer PUT /path2 ise, anında kabul etme, önce HTTP header'ına bak; X-My-Header: true varsa içeri al!)

4. Hepsini Birleştirelim: Kapsamlı (L3-L7) Politika Örneği

Sisteminizdeki bir uygulamanın hem kimden trafik alacağını (Ingress) hem de kime trafik gönderebileceğini (Egress) tek bir devasa kuralda birleştirebiliriz:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "example-policy"
spec:
  # Kural kime uygulanacak?
  endpointSelector:
    matchLabels:
      app: myapp
      
  # GELEN TRAFİK KURALLARI (Ingress)
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: "80"
              protocol: TCP
          rules:
            http:
              - method: "GET"
                path: "/public"
                
  # GİDEN TRAFİK KURALLARI (Egress)
  egress:
    - toEndpoints:
        - matchLabels:
            app: database
      toPorts:
        - ports:
            - port: "3306"
              protocol: TCP

Bu konfigürasyon, app=myapp etiketli pod'u zırh gibi sarar:

İçeriye sadece: frontend uygulamasından, 80 portuna ve sadece GET /public yoluna gelen istekleri alır.
Dışarıya sadece: database uygulamasının 3306 (MySQL) portuna veri gönderebilir. Başka hiçbir yere gidemez.

5. Kapsam (Scope): Namespace vs. Cluster-Wide

Son olarak, yazdığınız bu politikaların cluster içinde nereye etki edeceğini belirlemeniz gerekir. Cilium bu noktada iki farklı obje türü sunar:

Obje Türü (Kind)

Etki Alanı (Scope)

Ne Zaman Kullanılır?

CiliumNetworkPolicy

Tek bir Namespace

Sadece belirli bir projenin veya uygulamanın izolasyonunu sağlarken.

CiliumClusterwideNetworkPolicy

Tüm Namespace'ler

Tüm şirketi kapsayan global güvenlik kuralları yazarken (Örn: "Tüm cluster genelinde dışarıya DNS sorguları hariç tüm çıkışları engelle").

PreviousDemo

NextDemo

Last updated 6 months ago