Kubernetes NetworkPolicy ve Cilium ile Zero Trust Mikrosegmentasyon: Hubble Rehberi

Kubernetes kümelerinde ağ iletişimi varsayılan olarak düşündüğünüzden daha açıktır. Bir namespace içinde NetworkPolicy bulunmadığında pod'lar için ingress ve egress trafiği genel olarak serbesttir. Bir uygulamanın ele geçirilmesi, bu açık doğu-batı trafiğini keşif, kimlik bilgisi toplama ve yanal hareket için kullanılabilir hale getirir.

Bu rehber; standart Kubernetes NetworkPolicy ile temel izolasyonu, CiliumNetworkPolicy ile DNS ve HTTP katmanında daha ayrıntılı kuralları, Hubble ile akış gözlemlenebilirliğini ve güvenli bir default-deny geçiş planını uygulamalı biçimde ele alır. Amaç yalnız YAML üretmek değil, trafiği ölçerek kırmadan mikrosegmentasyon kurmaktır.

Kubernetes NetworkPolicy nasıl çalışır?

NetworkPolicy, pod'ların hangi kaynaklardan trafik alabileceğini ve hangi hedeflere trafik gönderebileceğini seçiciler üzerinden tanımlar. Kuralın gerçekten uygulanması için kümedeki CNI eklentisinin NetworkPolicy desteği olması gerekir. API nesnesinin başarıyla oluşturulması, veri düzleminde paketin engellendiğini tek başına kanıtlamaz.

Politikalar toplamsaldır. Aynı pod'ı seçen birden fazla allow kuralı varsa izinler birleşir; sonraki politika önceki izni geri alan klasik bir “deny override” gibi çalışmaz. Doğru model, pod'ı önce ilgili yönde izole etmek ve yalnız gereken akışları açıkça izinli hale getirmektir.

Kavram	Anlamı
podSelector	Politikanın uygulandığı pod kümesi
namespaceSelector	Kaynak veya hedef namespace seçimi
ipBlock	CIDR tabanlı ağ seçimi
policyTypes	Ingress, Egress veya ikisi
ports	Protokol ve port kısıtı
Boş selector	Namespace içindeki bütün pod'lar
Boş ingress/egress listesi	İlgili yönde trafik izni yok

Önce envanter: kim kiminle konuşuyor?

Default-deny politikasına doğrudan geçmek sık kesintinin temel nedenidir. Uygulamanın yalnız API ve veritabanı akışı değil; DNS, zaman senkronizasyonu, telemetry, secret store, lisans, webhook, container registry ve sağlık kontrolü bağımlılıkları da vardır.

En az bir iş döngüsü boyunca akışları gözlemleyin. Hubble; pod, namespace, label, servis ve politika kararı bağlamında akışları görmeye yardımcı olur. Düşük trafikli bakım işleri, aylık raporlar ve failover yolları kısa gözlem penceresinde görünmeyebilir. CMDB ve uygulama sahipliği bilgisi ağ telemetrisiyle birlikte kullanılmalıdır.

Namespace ve workload envanteri
Servisler, portlar ve protokoller
Küme DNS ve Kubernetes API bağımlılığı
Dış SaaS, güncelleme, lisans ve webhook hedefleri
Ingress controller, service mesh ve load balancer sağlık akışları
Prometheus scrape, log ve trace collector bağlantıları
CronJob ve düşük sıklıklı batch trafiği
Felaket kurtarma ve failover sırasında kullanılan yollar

Cilium ve Hubble neden birlikte kullanılır?

Cilium, Linux eBPF veri düzlemiyle Kubernetes ağ bağlantısı ve güvenlik politikası uygular. Hubble ise Cilium'un gözlemlenebilirlik katmanıdır; node, küme ve ClusterMesh kapsamındaki ağ akışlarını kimlik ve label bilgisiyle görünür hale getirir.

Standart NetworkPolicy taşınabilir bir L3/L4 temel sunar. CiliumNetworkPolicy; DNS isimleri, HTTP yöntemleri ve yolları gibi L7 bağlamı ekleyebilir. Hubble da izin verilen ve reddedilen akışların nedenini göstererek politika geliştirme döngüsünü kısaltır.

Bu üç katmanı şöyle ayırın:

Standart NetworkPolicy: taşınabilir namespace, pod, CIDR ve port izolasyonu.
CiliumNetworkPolicy: Cilium'a özgü DNS, FQDN ve L7 denetimi.
Hubble: akış görünürlüğü, politika sonucu, servis haritası ve sorun giderme.

Cilium ve Hubble kurulumu

Kurulum değerleri dağıtıma göre değişir. Üretimde GKE, AKS, EKS, RKE2, Talos veya on-prem için Cilium'un ilgili resmi kurulum sayfasını kullanın. Aşağıdaki Helm yaklaşımı genel bir örnektir; sürümü yayın anındaki doğrulanmış kararla sabitleyin ve önce test kümesinde deneyin.

CODE TERMINAL

helm install cilium oci://quay.io/cilium/charts/cilium \
  --version 1.20.1 \
  --namespace kube-system \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true

cilium status --wait
cilium hubble port-forward &
hubble status

OCI chart'ı tag yerine digest ile sabitlemek tekrarlanabilirliği artırır. İmzayı Cosign ile doğrulayın; Helm values dosyasını sürüm kontrolünde tutun. Kube-proxy replacement, IPAM, native routing ve encryption seçenekleri altyapıya göre tasarlanmalıdır; internetten kopyalanmış tek bir values dosyasını bütün kümelere uygulamayın.

Default-deny ingress ve egress

Bir namespace'i her iki yönde izole eden temel politika şöyledir:

CODE TERMINAL

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: payments
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Bu politika tek başına uygulandığında bütün seçili pod'ların ingress ve egress trafiği kesilir. Egress izolasyonu DNS'i de engeller. Uygulama sahipleri “veritabanına erişim gitti” sanırken gerçek neden isim çözümlemesinin durması olabilir. Bu nedenle DNS izni ilk bağımlılıklardan biridir.

DNS erişimini güvenli biçimde açmak

Standart NetworkPolicy ile küme DNS pod'larına UDP ve TCP 53 erişimi verilebilir. Namespace ve label değerleri dağıtıma göre değişebileceğinden CoreDNS/KubeDNS etiketlerini kümenizden doğrulayın.

CODE TERMINAL

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-cluster-dns
  namespace: payments
spec:
  podSelector: {}
  policyTypes: [Egress]
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

DNS'e izin vermek, çözülen bütün hedeflere erişim izni vermek değildir. Standart politika IP ve port tabanında devam eder. Cilium'un DNS-aware politikası ile yalnız belirli alan adlarına sorgu ve bağlantı izni üretilebilir.

Frontend'den API'ye minimum ingress

Örnek uygulamada frontend pod'larının api pod'larına yalnız TCP 8080 üzerinden erişmesine izin verelim:

CODE TERMINAL

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-from-frontend
  namespace: payments
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes: [Ingress]
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

podSelector burada aynı namespace içinde değerlendirilir. Başka namespace'ten kaynak seçilecekse namespaceSelector ekleyin. Selector'ların aynı from öğesi içinde veya ayrı öğelerde yazılması mantığı değiştirir: aynı öğede namespace VE pod şartı, ayrı öğelerde namespace VEYA pod şartı oluşabilir.

Namespace etiketlerini güven sınırı olarak kullanmak

Kubernetes, namespace adı için kubernetes.io/metadata.name etiketini sağlar. Yalnız namespace adına güvenmek yerine ortam ve sahiplik gibi kontrollü etiketler de kullanılabilir.

CODE TERMINAL

kubectl label namespace payments \
  security.trsiber.net/zone=restricted \
  security.trsiber.net/owner=payment-platform

Bu etiketleri herkes değiştirebiliyorsa ağ politikası güven sınırı değildir. Namespace update yetkisi RBAC ile daraltılmalı, admission politikasıyla güvenlik etiketlerinin yalnız platform veya güvenlik ekibince değiştirilebilmesi sağlanmalıdır.

API'den veritabanına egress

CODE TERMINAL

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-to-postgres
  namespace: payments
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes: [Egress]
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: postgres
      ports:
        - protocol: TCP
          port: 5432

PostgreSQL başka namespace'teyse hem namespaceSelector hem podSelector aynı hedef nesnesinde kullanılmalıdır. Veritabanı küme dışındaysa CIDR kuralı düşünülebilir; ancak bulut load balancer, NAT ve node davranışları nedeniyle paketin NetworkPolicy katmanında gördüğü kaynak/hedef IP değişebilir. Üretim CNI dokümantasyonunu ve gerçek akışı test edin.

Cilium ile FQDN tabanlı egress

IP adresleri sık değişen SaaS hedefleri için statik CIDR listesi kırılgandır. Cilium toFQDNs ile belirli DNS adlarına egress kuralı tanımlayabilir.

CODE TERMINAL

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-to-approved-saas
  namespace: payments
spec:
  endpointSelector:
    matchLabels:
      app: api
  egress:
    - toEndpoints:
        - matchLabels:
            k8s:io.kubernetes.pod.namespace: kube-system
            k8s:k8s-app: kube-dns
      toPorts:
        - ports:
            - port: "53"
              protocol: ANY
          rules:
            dns:
              - matchName: api.example-saas.com
    - toFQDNs:
        - matchName: api.example-saas.com
      toPorts:
        - ports:
            - port: "443"
              protocol: TCP

DNS tabanlı politikanın güven modeli önemlidir. L7 DNS proxy yalnız güvenilir küme DNS'ine yöneltilmelidir. Pod'un harici ve kontrolsüz bir resolver kullanmasına izin verilirse saldırgan DNS yanıtlarıyla izin verilen IP listesini etkileyebilir. Split-horizon DNS, CNAME zincirleri, TTL ve CDN davranışı test planına alınmalıdır.

HTTP yöntem ve yol kısıtı

Cilium L7 HTTP kuralları, TCP 8080 üzerindeki erişimi yöntem ve path'e göre daraltabilir:

CODE TERMINAL

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: frontend-to-api-l7
  namespace: payments
spec:
  endpointSelector:
    matchLabels:
      app: api
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: "GET"
                path: "^/v1/catalog/.*"
              - method: "POST"
                path: "^/v1/checkout$"

L7 politika uygulaması proxy yolunu devreye alabilir ve kapasite planını etkiler. Header, path normalizasyonu, URL encoding, gRPC ve uzun bağlantılar için davranış ayrıca sınanmalıdır. Ağ politikası uygulama yetkilendirmesinin yerine geçmez; kullanıcı ve nesne düzeyi kontrol uygulamada kalmalıdır.

Hubble ile akışları gözlemlemek

CODE TERMINAL

hubble observe --namespace payments --follow

hubble observe \
  --namespace payments \
  --verdict DROPPED \
  --since 15m

hubble observe \
  --from-pod payments/api \
  --protocol http \
  --since 5m

Dropped akışlar politika hatalarını ve yetkisiz keşfi gösterebilir. Her drop güvenlik olayı değildir; readiness probe, service discovery veya unutulmuş telemetry bağımlılığı da olabilir. Akıştaki source, destination, namespace, label, port, protocol ve drop reason birlikte değerlendirilmelidir.

Hubble Relay küme genelinde görünürlük sağlar. Hubble UI servis haritası bağımlılık keşfini kolaylaştırır; ancak hassas URL ve header verilerinin görünürlüğü veri sınıflandırması açısından incelenmelidir. L7 akışlarında redaction seçenekleri kullanılmalı, arayüz erişimi kimlik ve ağ politikasıyla korunmalıdır.

Policy verdict metrikleri

Hubble metrikleri Prometheus'a aktarılıp Grafana ve SIEM ile izlenebilir. Yararlı ölçümler arasında drop oranı, kaynak ve hedef namespace, protokol, DNS hata oranı ve HTTP durum kodları bulunur. Yüksek cardinality oluşturacak label'lar dikkatli seçilmelidir.

Yeni deploy sonrasında dropped flow sıçraması
Bir workload'dan çok sayıda farklı hedefe bağlantı denemesi
Beklenmeyen namespace sınırı geçişleri
DNS NXDOMAIN ve reddedilen alan adı kümeleri
İzin verilmeyen portlara yatay tarama davranışı
İnternete ilk kez bağlantı kuran pod
Politika uygulanmayan endpoint sayısında artış

Audit'ten enforcement'a geçiş

Politikayı tek bakım penceresinde bütün kümeye yaymak yerine kademeli ilerleyin:

Gözlem: Hubble ile mevcut akışları toplayın, sahiplerle doğrulayın.
Etiket hijyeni: app, component, owner ve zone etiketlerini standartlaştırın.
Tek namespace pilotu: düşük riskli uygulamada ingress default-deny uygulayın.
DNS ve telemetry: ortak bağımlılıkları ayrı politikalarla açın.
Uygulama akışları: servis çiftlerini ve gerekli portları allowlist'e alın.
Egress default-deny: dış hedefleri FQDN, service veya CIDR ile sınırlandırın.
L7 politikası: yalnız iş ihtiyacı ve performans testi bulunan akışlara ekleyin.
Canary ve rollback: az sayıda replica/namespace ile enforce edin.
Alarm ve sahiplik: dropped akış için ekip, eşik ve çalışma kitabı tanımlayın.
Sürekli kontrol: yeni servisin politikasız üretime çıkmasını admission ile engelleyin.

Canary test senaryosu

Pozitif ve negatif testleri birlikte yazın. Yalnız uygulamanın çalıştığını görmek geniş bir allow kuralını yakalamaz.

Test	Beklenen sonuç
Frontend -> API TCP 8080	İzin
Frontend -> API TCP 22	Ret
Başka namespace -> API 8080	Ret
API -> PostgreSQL 5432	İzin
Frontend -> PostgreSQL 5432	Ret
API -> Küme DNS 53	İzin
API -> Onaysız harici alan 443	Ret
API -> Onaylı SaaS 443	İzin
API -> Onaylı SaaS farklı port	Ret
Yetkisiz HTTP path	L7 politika ile ret

Testler ephemeral debug pod ile yürütülebilir; ancak üretimde kalıcı geniş yetkili debug image bırakılmamalıdır. Test sonucu Hubble verdict'i ve uygulama yanıtıyla birlikte kaydedilmelidir.

Sık yapılan selector hataları

Yanlış label anahtarı nedeniyle hiçbir pod'ı seçmeyen politika
Boş podSelector'ın bütün namespace'i seçtiğini unutmak
namespaceSelector ve podSelector'ı ayrı maddelere yazıp OR oluşturmak
policyTypes alanını eksik bırakıp yalnız tek yönü izole etmek
Adlandırılmış portun seçili pod'larda tanımlı olmaması
Service port ile container targetPort'u karıştırmak
Egress default-deny sonrasında DNS'i açmamak
Node, hostNetwork ve externalTrafficPolicy davranışını test etmemek
CNI'nin policy desteğini ve enforcement durumunu doğrulamamak

Policy-as-code ve CI doğrulaması

NetworkPolicy dosyaları uygulama kodu gibi review ve test sürecinden geçmelidir. Şema kontrolü, yasak wildcard'lar, zorunlu sahiplik etiketleri ve default-deny varlığı CI'da doğrulanabilir. Değişiklik PR'ında etkilenen source-destination matrisi gösterilmelidir.

CODE TERMINAL

kubectl apply --server-side --dry-run=server -f policies/

cilium policy validate policies/cilium/

Komutların desteklediği seçenekler kullanılan Cilium sürümüne göre doğrulanmalıdır. Admission katmanında production namespace'in politikasız kalmasını veya güvenlik etiketinin kaldırılmasını engelleyen kurallar eklenebilir. Break-glass istisnasının sahibi, nedeni ve bitiş tarihi olmalıdır.

GitOps sıralama riski

Yeni namespace oluşturulup workload'lar çalıştıktan sonra politika gelirse kısa bir açık pencere oluşur. Tersine default-deny önce gelir, allow kuralları gecikirse başlangıç kesintisi oluşabilir. GitOps aracı sync wave, bağımlılık ve health check özellikleriyle sıra kontrol edilmelidir.

Güvenli desenlerden biri namespace oluştururken baseline default-deny ve DNS politikasını aynı platform paketiyle sağlamaktır. Uygulama deployment'ı, gerekli allow politikaları hazır olmadan healthy kabul edilmemelidir.

HostNetwork, node ve kontrol düzlemi trafiği

Standart NetworkPolicy pod trafiğine odaklanır; hostNetwork pod'ları, node-originated trafik ve Kubernetes API erişimi CNI ve dağıtım ayrıntılarına bağlıdır. Kubelet probe, NodePort, ingress controller ve external load balancer health check yolları özel test gerektirir.

Cilium host firewall ve cluster-wide policy gibi ek yetenekler sunabilir. Bu kontrollerin normal namespace politikasından daha geniş etkisi vardır; ayrı change, canary ve rollback planıyla uygulanmalıdır. Kontrol düzlemi endpoint'lerini yanlışlıkla engellemek bütün kümenin yönetimini etkileyebilir.

Service mesh ile çakışma

Sidecar proxy kullanılan kümelerde uygulama trafiğinin kaynak ve hedef görünümü değişebilir. NetworkPolicy yalnız sidecar portunu görürken L7 yetkilendirme mesh katmanında yapılabilir. Ambient veya sidecarless mimarilerde davranış farklıdır.

Tek bir akışı iki katmanda da kontrol etmek savunmayı güçlendirebilir, fakat sahiplik belirsizse sorun giderme karmaşıklaşır. L3/L4 sınırını Cilium, servis kimliği ve uygulama protokol yetkisini mesh veya uygulama katmanının yönetmesi açıkça belgelenmelidir.

Performans ve kapasite

Binlerce selector, yüksek cardinality Hubble etiketi ve yoğun L7 proxy kullanımı kontrol ve veri düzlemi maliyetini artırabilir. Politika sayısı tek başına yeterli ölçü değildir; endpoint regeneration süresi, policy calculation, proxy memory, flow export hacmi ve Prometheus cardinality izlenmelidir.

Politikaları gereksiz yere workload başına kopyalamak yerine sahiplik ve güven sınırına göre yeniden kullanılabilir desenler oluşturun. Buna karşılık tek bir dev cluster-wide allowlist de değişiklik blast radius'unu büyütür. Denge, gözlenebilir küçük politika birimleri ve kontrollü varsayılanlardan gelir.

Olay müdahalesinde Hubble kullanımı

Bir pod'ın ele geçirildiği şüphesinde Hubble geçmiş akışları yanal hareket kapsamını belirlemeye yardımcı olabilir. Şüpheli pod'ın konuştuğu servisler, reddedilen tarama denemeleri, dış DNS adları ve yeni hedefler çıkarılabilir.

Pod UID, image digest, node ve namespace bilgisini kaydedin.
İlgili zaman aralığında source pod'a göre Hubble akışlarını dışa aktarın.
DNS sorguları ile gerçek bağlantıları eşleştirin.
İzin verilen ama iş akışında beklenmeyen hedefleri belirleyin.
NetworkPolicy değişiklik zamanlarını deploy ve alarm zamanlarıyla karşılaştırın.
Karantina politikası uygulamadan önce gerekli adli telemetriyi koruyun.
Aynı image digest'i kullanan diğer pod'larda benzer akışları arayın.

Hubble tam paket yakalama değildir ve uygulama içeriğinin tamamını sağlamaz. EDR, audit log, container runtime, Kubernetes audit ve bulut akış kayıtlarıyla birlikte kullanılmalıdır.

Üretim kontrol listesi

CNI'nin NetworkPolicy enforcement desteği doğrulandı.
Her üretim namespace'inde ingress ve egress baseline politikası var.
DNS yalnız güvenilir küme resolver'ına açık.
Uygulama bağımlılık matrisi sahibi tarafından onaylandı.
Dış SaaS hedefleri FQDN/CIDR davranışıyla test edildi.
Namespace güvenlik etiketleri RBAC ve admission ile korunuyor.
Pozitif ve negatif bağlantı testleri CI veya canary sürecinde çalışıyor.
Dropped flow alarmlarının sahibi ve runbook'u var.
Hubble L7 verisi için redaction ve erişim kontrolü uygulandı.
HostNetwork, node, ingress ve health-check yolları test edildi.
GitOps uygulama sırası açık pencere ve kesintiyi önlüyor.
Break-glass politikalarının otomatik bitiş tarihi bulunuyor.
Politika değişiklikleri audit log ve sürüm kontrolünde izleniyor.
Rollback, politika kaldırmak yerine güvenli önceki sürüme dönüş sağlıyor.

Sonuç

Kubernetes mikrosegmentasyonu bir kerelik default-deny YAML'ı değildir. Başarılı yaklaşım; trafiği Hubble ile gözlemek, taşınabilir L3/L4 tabanını standart NetworkPolicy ile kurmak, gerekli yerlerde Cilium'un DNS ve L7 yeteneklerini eklemek ve enforcement'ı canary testlerle kademeli genişletmektir.

En değerli çıktı politika sayısı değil, doğrulanmış bir iletişim sözleşmesidir: hangi workload, hangi kimlikle, hangi namespace'ten, hangi hedefe, hangi port ve protokolle erişebilir? Bu sözleşme kod, telemetri ve değişiklik yönetimiyle yaşatıldığında yanal hareket alanı daralır ve olay araştırması hızlanır.

Kaynaklar

TR Siber Ekibi Yazar · X

Kaynak bağlantısı ← Ana sayfaya dön