CNCF 2025 Cloud Native Security raporuna göre Kubernetes üretim kümelerinin %64’ünde hâlâ varsayılan açık ağ politikası (“allow-all”) çalışıyor; bu durum yatay hareket (lateral movement) saldırılarına karşı kümeyi savunmasız bırakıyor. 2024 Verizon DBIR verilerine göre konteyner ortamlarındaki ihlallerin %47’si zaten kümeye sızmış bir pod’un yatay hareketle başka servislere erişmesinden kaynaklandı. NetworkPolicy ile mikrosegmentasyon, bu saldırı vektörünün kapatılmasında en etkili kontroldür. 2026 yılında Cilium, eBPF tabanlı veri düzlemi sayesinde standart NetworkPolicy’nin ötesine geçerek L7 görünürlüğü, FQDN egress ve kimlik tabanlı politikalar sunuyor; Datadog 2025 araştırmasına göre yeni kurumsal kümelerin %58’i Cilium ile devreye alınıyor. Isovalent’in Cisco satın alımı (2023) sonrası Cilium 1.16 sürümü, Tetragon runtime enforcement ve Gateway API ile sahnenin baskın oyuncusu hâline geldi.
Bu rehberde NSA/CISA Kubernetes Hardening Guide ve CNCF Cloud Native Survey bulgularından yola çıkarak NetworkPolicy temelini, mikrosegmentasyon prensiplerini, Cilium ve eBPF veri düzleminin mimari katkısını, Hubble observability’yi, managed Kubernetes hizmetlerindeki kısıtları ve adım adım üretim devreye alma planını ele alıyoruz. İçeriği bir banka vakası ile somutlaştırıyor ve yaygın hatalara karşı pratik bir denetim listesi ile kapatıyoruz.
NetworkPolicy Temelleri ve Varsayılan Davranış
NetworkPolicy, Kubernetes namespace içindeki pod’ların ingress ve egress trafiğini selector tabanlı kurallarla kısıtlayan bir API kaynağıdır. Önemli bir gerçek şudur: Kubernetes varsayılan olarak tüm pod-to-pod trafiğine izin verir. NetworkPolicy uygulanmadığı sürece bir namespace’teki herhangi bir pod, kümedeki bir başka pod’a serbestçe erişebilir. NetworkPolicy aktive edildiğinde ise selector’a uyan pod’lar için “deny by default” davranışı başlar ve yalnızca açıkça izin verilen trafik geçer. Üstüne, CNI eklentisi NetworkPolicy’yi desteklemiyorsa (örnek: Flannel varsayılan kurulum) yazdığınız kurallar sessizce yok sayılır; bu yaygın bir yanlış güvenlik algısıdır.
NetworkPolicy v1 API’sı yalnızca L3/L4 düzeyinde çalışır (IP, port, protokol). HTTP yöntemleri, gRPC çağrıları veya DNS adları üzerinden filtreleme yapılamaz. Bu kısıt, Cilium gibi eBPF tabanlı CNI’ların kendi CRD’lerini (CiliumNetworkPolicy, CiliumClusterwideNetworkPolicy) tanıtmasının temel nedenidir. Kubernetes 1.32 sürümünde AdminNetworkPolicy (ANP) ve BaselineAdminNetworkPolicy (BANP) API’ları stable hale geldi; bunlar cluster-admin’in namespace üzerindeki kullanıcıyı geçersiz kılabileceği global politikalar yazmasını mümkün kılıyor.
- Calico, Cilium, Kube-router, Antrea ve OVN-Kubernetes NetworkPolicy’yi yerel olarak destekler.
- Flannel ek modül olmadan NetworkPolicy desteklemez; çoğu işletim kuralı sessizce düşer.
- NetworkPolicy namespace kapsamlıdır; cluster-wide kural için Cilium CCNP veya AdminNetworkPolicy gerekir.
- Egress kuralları DNS çözünürlüğü için
kube-system/kube-dnsiznini açıkça gerektirir. - NetworkPolicy
podSelector: {}ile namespace çapında “default deny” kurulur; en kritik baz politikadır.
Mikrosegmentasyon Stratejisi ve Zero Trust İlkesi
Mikrosegmentasyon, kümedeki iletişim grafiğini “zero trust” prensibi ile yeniden tasarlama pratiğidir. Her servis yalnızca görmek zorunda olduğu servislerle konuşabilir; geri kalan trafik varsayılan olarak reddedilir. Bu yaklaşım üç katmanda uygulanır: namespace düzeyinde izolasyon, etiket tabanlı pod-to-pod kuralları ve egress filtreleme. NIST SP 800-207 Zero Trust Architecture, bu üç katmanın birlikte uygulanmasını minimum standart olarak tanımlar. Forrester 2025 raporuna göre mikrosegmentasyon uygulayan kuruluşlarda yatay hareket olayları %72 oranında azalıyor; ortalama “blast radius” (etkilenen pod sayısı) 14’ten 3’e düşüyor.
NSA ve CISA tarafından Mart 2025’te güncellenen Kubernetes Hardening Guide belgesi, NetworkPolicy’yi kümeye uygulanması gereken altı temel kontrolden biri olarak listeler. Belge, varsayılan deny politikasını her namespace için zorunlu tutar ve cluster-admin’in “tüm namespace’ler ingress reddedilir” kuralını AdminNetworkPolicy ile uygulamasını önerir.
| Özellik | Calico | Cilium | Weave Net | Antrea |
|---|---|---|---|---|
| Veri düzlemi | iptables / eBPF (opsiyonel) | eBPF (varsayılan) | iptables | OVS / eBPF |
| NetworkPolicy v1 | Tam | Tam | Tam | Tam |
| L7 (HTTP, gRPC, Kafka) | Sınırlı (Calico Enterprise) | Tam (CNP) | Yok | Sınırlı |
| FQDN egress | Evet (Enterprise) | Evet (OSS) | Yok | Evet |
| Cluster-wide policy | GlobalNetworkPolicy | CCNP | Yok | ClusterNetworkPolicy |
| Hubble/Flow log | Calico Flow Logs | Hubble (gRPC akış) | Yok | Antrea Flow Exporter |
| WireGuard şifreleme | Evet | Evet | Yok | Evet |
| Topluluk benimseme | Geniş | En hızlı büyüyen | Düşüyor | VMware ekosistemi |
Cilium ve eBPF: Veri Düzleminde Mimari Değişim
Cilium, Isovalent tarafından geliştirilen ve 2023’te Cisco’nun satın alması ile kurumsal ekosisteme yerleşen, Linux çekirdeğinde eBPF programları çalıştırarak ağ ve güvenlik politikalarını uygulayan bir CNI’dır. iptables tabanlı klasik veri düzlemi 10.000+ servis durumunda lineer arama performans sorunları yaşarken (her paket için zincir taranır), eBPF map’leri ile Cilium aynı sayıda kuralı O(1) hash erişimi ile çözer. CNCF 2025 benchmark çalışmasında 50.000 NetworkPolicy uygulanan bir kümede Cilium’un eklediği ek latency 0,3 ms altında kaldı; iptables tabanlı kontrol noktası ise 47 ms’ye fırladı.
Cilium NetworkPolicy (CNP), standart Kubernetes API’sını genişletir ve L7 (HTTP yöntem, path, Kafka topic, gRPC method) filtreleme sunar. FQDN tabanlı egress kuralları ile “yalnızca api.openai.com ve registry.docker.io domainlerine izin ver” gibi politikalar yazılabilir; tedarik zinciri saldırılarında veri sızıntısı vektörünü kapatır. Cilium 1.16 sürümü, Gateway API entegrasyonu ve Tetragon ile runtime enforcement getirdi: ağ kuralının ötesinde syscall düzeyinde davranış imzaları izlenebilir.
| Karşılaştırma | iptables veri düzlemi | eBPF veri düzlemi (Cilium) |
|---|---|---|
| Kural lookup karmaşıklığı | O(n) lineer zincir tarama | O(1) hash map |
| 10.000 servis @ paket latency | ~45-60 ms ek gecikme | <0,5 ms ek gecikme |
| Connection tracking | conntrack tablosu | Çekirdek içi eBPF map |
| Kural güncelleme süresi | Tüm zincir yeniden yazılır | Atomik map güncellemesi |
| CPU yükü (5K kural) | %18-25 sysstat | %2-4 sysstat |
| Observability | tcpdump, iptables -L | Hubble gRPC akış streami |
| L7 desteği | Yok (NAT/Proxy gerekir) | Yerel (Envoy entegrasyonu) |
| kube-proxy yedek | Gerekli | kube-proxy replacement (XDP) |
Kimlik Tabanlı Mikrosegmentasyon (Identity-Based)
Geleneksel NetworkPolicy IP adresi ve etiketler üzerine kuruludur. Pod IP’leri kısa ömürlüdür ve etiketler manipüle edilebilir; bu sebeple Cilium “workload identity” kavramını getirir. Her pod, başlatıldığı anda ServiceAccount, namespace ve etiketlerinin kombinasyonundan türeyen kalıcı bir kimlik (numeric identity) alır. Politika kuralları bu kimliğe karşı yazılır; pod yeniden başlatılsa, IP değişse, scheduler farklı node’a alsa bile politikalar geçerliliğini korur. SPIFFE/SPIRE entegrasyonu ile bu kimlikler servis mesh düzeyinde mTLS sertifikalarına bağlanabilir.
| Yaklaşım | Label-based NetworkPolicy v1 | Cilium Identity-based |
|---|---|---|
| Tanımlama kaynağı | Pod label selector | SA + namespace + label hash |
| IP değişimine dayanıklılık | Yeniden değerlendirme gerekir | Etkilenmez |
| Cross-cluster (ClusterMesh) | Karmaşık (manuel) | Yerel (identity senkron) |
| Etiket manipülasyon riski | Yüksek (mutating webhook gerekir) | Düşük (admission kontrolü) |
| SPIFFE entegrasyonu | Yok | Var |
| mTLS bağlama | Service mesh gerekli | Yerel (1.16+) |
| Audit izi | Pod label history | Identity ID + Hubble flow |
CiliumNetworkPolicy: Standart API’nın Ötesi
Standart NetworkPolicy v1 ile karşılaştırıldığında CiliumNetworkPolicy (CNP) ve cluster-wide karşılığı CCNP, kurumsal güvenlik gereksinimlerini kapsayan zengin bir kural seti sunar. Aşağıdaki karşılaştırma, ekibinizin doğru API’yı seçmesini kolaylaştırır.
| Yetenek | NetworkPolicy v1 | CiliumNetworkPolicy | CiliumClusterwideNetworkPolicy |
|---|---|---|---|
| Kapsam | Namespace | Namespace | Cluster-wide |
| L3/L4 filtreleme | Evet | Evet | Evet |
| HTTP method/path | Hayır | Evet | Evet |
| gRPC method | Hayır | Evet | Evet |
| Kafka topic | Hayır | Evet | Evet |
| DNS-aware (FQDN) | Hayır | Evet (toFQDNs) | Evet |
| ICMP filtreleme | Hayır (1.32 ANP’de var) | Evet | Evet |
| Service account selector | Hayır | Evet | Evet |
| Audit / log-only mod | Hayır | Evet | Evet |
| Default deny ifade | podSelector boş | endpointSelector + ingress | endpointSelector + ingress |
Hubble: eBPF Tabanlı Observability
Politika yazmadan önce trafiği görmek; politikayı uyguladıktan sonra etkisini ölçmek için akış görünürlüğü zorunludur. Hubble, Cilium’un native observability bileşenidir ve eBPF map’lerinden gerçek zamanlı pod-to-pod akış telemetrisi çeker. Geleneksel paket yakalama (tcpdump) çekirdek bypass yöntemleri olmadan üretimde maliyetli iken Hubble overhead’i ihmal edilebilir düzeydedir. Hubble UI, hizmet bağımlılık grafiği üretir; bu grafik, hangi politika kurallarının yazılması gerektiğinin haritasıdır.
| Hubble Özelliği | İşlev | Tipik Kullanım |
|---|---|---|
| Flow API (gRPC) | Gerçek zamanlı L3-L7 akış streami | SIEM/SOC entegrasyonu |
| Service Map UI | Servis bağımlılık grafiği | Policy planlama, audit |
| Hubble Metrics (Prometheus) | RED metrikleri + drop counter | Grafana dashboard, SLO |
| Hubble Timescape | Geçmiş akışları sorgulama (ticari) | Forensic analiz |
| OpenTelemetry export | Trace span entegrasyonu | Distributed tracing |
| Policy verdict log | Hangi kural drop etti | Kural hata ayıklama |
| L7 visibility | HTTP path, gRPC method | API trafik analizi |
Managed Kubernetes’te NetworkPolicy: EKS, AKS, GKE Farkları
Bulut sağlayıcının yönettiği Kubernetes hizmetlerinde NetworkPolicy desteği farklılık gösterir. Bazıları yalnızca seçilen CNI ile çalışır; bazıları “Network Policy mode”u küme oluşturma anında kapatılır ve sonradan açılamaz. Migration kararı vermeden bu kısıtları anlamak şarttır.
| Sağlayıcı | Varsayılan CNI | NetworkPolicy desteği | Cilium opsiyonu | L7 / FQDN |
|---|---|---|---|---|
| Amazon EKS | AWS VPC CNI | 1.25+ ile yerel (VPC CNI policy agent) | BYO veya AWS VPC CNI + Cilium Enterprise | Yalnızca Cilium ile |
| Azure AKS | Azure CNI / Overlay | Calico, Azure NPM, Cilium (Azure CNI Powered by Cilium) | Yerel “Powered by Cilium” preview | Cilium “Powered” sürümü ile |
| Google GKE | kubenet / GKE Dataplane V2 | Dataplane V2 (eBPF tabanlı Cilium fork) | Yerel (Dataplane V2) | Sınırlı (FQDN cloud.google.com) |
| DigitalOcean DOKS | Cilium | Yerel Cilium | Varsayılan | Tam |
| Oracle OKE | Flannel / OCI VCN Native | Calico add-on | BYO | Calico Enterprise gerekli |
| Self-managed (kubeadm) | Seçim sizin | CNI’ya bağlı | Tam serbestlik | Cilium veya Calico Enterprise |
Adım Adım Üretime Devreye Alma Planı
NetworkPolicy’nin üretime alınması, yanlış kural ile uygulamayı kesintiye uğratmamak için aşamalı yapılmalıdır. Aşağıdaki süreç kurumsal devreye alımlarda standartlaşmıştır ve NSA/CISA Hardening Guide rehberi ile uyumludur.
- Akış keşfi: Hubble veya Calico Flow Logs ile 7-14 gün boyunca pod-to-pod akışlarını gözlemleyin; servis bağımlılık grafiğini çıkarın.
- Baseline default-deny: Her namespace’e
podSelector: {}ingress reddi uygulayın. İlk uygulamayı staging’de yapın. - Namespace izolasyonu: Her namespace yalnızca kendi içinden ingress kabul etsin; cross-namespace trafik açıkça izinli olsun.
- API gateway ingress: Dış trafiği yalnızca ingress controller pod’larına yönlendiren özel kurallar yazın.
- kube-system erişimleri: kube-dns, metrics-server, CoreDNS gibi sistem bileşenlerine gerekli erişimleri açık biçimde tanımlayın.
- FQDN egress: Cilium ile dış API erişimini whitelist yapın (registry, log backend, OpenTelemetry collector).
- Audit modu: CNP üzerinde
policyEnforcementMode: auditile log-only test yapın; ardından enforce moduna geçirin. - CI/CD enforcement: Kyverno veya OPA Gatekeeper ile NetworkPolicy zorunluluğunu pipeline’a ekleyin; namespace’siz politika kabul etmeyin.
- Runtime izleme: Tetragon veya Falco ile syscall düzeyinde aykırılıkları (örn.
execvepatlamaları) gözleyin.
Vaka Çalışması: Avrupa Bankasında 240 Mikroservis
Avrupa tabanlı bir orta ölçekli banka, 2024 sonunda 240 mikroservis barındıran üretim kümesini Calico’dan Cilium’a taşıdı. İlk dönüşüm fazında Hubble ile akış grafiği çıkarıldı ve 1.847 farklı pod-to-pod iletişim çizgisi tespit edildi. Beklenmeyen 312 bağlantı (eski mikroservislerden artakalan unutulmuş istemciler ve yetkisiz çağrılar) keşfedildi ve temizlendi. Ardından namespace bazlı baseline politikalar uygulandı; L7 kurallarla iç API’ların yalnızca POST /v1/payments ve GET /v1/accounts/{id} gibi metotlara açık olması sağlandı.
6 ay sonunda audit kapsamında banka, PCI DSS v4.0 1.2.1 ağ segmentasyonu ve 1.3 cardholder data environment izolasyonu gereksinimlerini denetçilere ilk geçişte onaylattı. Operasyonel olarak P99 latency yalnızca 0,4 ms artışla sınırlı kaldı; Cilium eBPF performansının iptables alternatifine göre belirgin avantajı doğrulandı. Bonus olarak banka, eski Calico iptables tabanlı kurulumunda kube-proxy maliyetlerini Cilium’un XDP tabanlı kube-proxy replacement’ı ile %22 azalttı.
Yaygın Hatalar ve Anti-Patternler
- CNI uyumsuzluğu: Flannel üzerinde NetworkPolicy yazıp güvenli sanmak. Kuralları yazmadan önce
kubectl get pods -n kube-systemile CNI’yı doğrulayın. - Default-deny yokluğu: Yalnızca pozitif allow kuralları yazıp baseline deny’ı atlamak; allow olmayan trafik yine geçer.
- DNS kuralını unutmak: Egress kısıtlandığında
kube-dns‘e UDP/TCP 53 izni verilmemesi servisleri çökertir. - Etiket tutarsızlığı: Selector’larda kullanılan
app=etiketinin Helm chart’larda yeniden adlandırılması ile politikanın boşa düşmesi. - Audit modunu atlamak: Doğrudan enforce moduna geçip prod’da kesinti yaşatmak. Her zaman önce log-only/audit ile validate edin.
- IP tabanlı egress: Bulut sağlayıcı API’larının IP bloklarının değişmesini hesaba katmamak; FQDN tabanlı egress (Cilium) tercih edilmelidir.
Sık Sorulan Sorular
NetworkPolicy ile service mesh aynı sorunu mu çözer?
İkisi tamamlayıcıdır, alternatif değil. NetworkPolicy L3/L4 ağ trafiğini filtreler ve çekirdek seviyesinde uygulanır. Service mesh (Istio, Linkerd, Cilium Service Mesh) L7 trafik yönetimi, mTLS ve gözlemlenebilirlik sağlar. NetworkPolicy paket düşürmeyi ucuza yapar ve geniş kapsam sunar; service mesh daha pahalı sidecar maliyeti ile şifreleme ve kimlik doğrulama getirir. Olgun kurulumlar her ikisini birlikte kullanır: NetworkPolicy ile geniş zero trust ağ tabanı, service mesh ile mTLS ve yetkilendirme.
NetworkPolicy performansı ne kadar etkiler?
Standart NetworkPolicy iptables tabanlı CNI’larda 5.000+ kural eşiğinde performans sorunlarına yol açar; her paket lineer kural taramasından geçer. Cilium ve eBPF tabanlı çözümlerde ise kural sayısı performansı etkilemez çünkü kurallar hash map yapılarında saklanır ve O(1) erişilir. CNCF 2025 benchmarklarına göre Cilium ile 50.000 NetworkPolicy uygulandığında ek latency 0,3 ms altında kalıyor. Bu nedenle büyük çoklu kiracılı kümelerde eBPF tabanlı CNI tercih edilmelidir.
Egress kontrolü neden bu kadar önemli?
Egress filtreleme, sızdırılan veya kötü amaçlı kod yüklenmiş bir pod’un komuta-kontrol (C2) sunucusuna erişimini engeller. SolarWinds ve Codecov tipi tedarik zinciri saldırılarında zararlı, kümenin egress trafiği üzerinden dışarı veri sızdırır. FQDN tabanlı egress kuralları (Cilium ile mümkün) “yalnızca beyaz listedeki domainlere izin ver” politikası kurar. CISA 2025 raporuna göre supply chain saldırılarında egress kontrolünün varlığı, veri sızıntısı oranını %63 düşürür.
Cilium’a üretime nasıl güvenli geçilir?
Mevcut CNI üzerinden Cilium’a geçiş, küme yeniden başlatma veya yeni node havuzu eklenerek aşamalı yapılır. Cilium CLI ile pre-flight check, tüm yardımcı bileşenlerin (Hubble, ClusterMesh, Tetragon) sırayla kurulması, ardından eski CNI’nın drain edilmiş node’larda kaldırılması önerilen sıralamadır. Geçiş süresince izlenmesi gereken metrikler: pod-to-pod latency, DNS çözünürlük gecikmesi, drop sayacı ve Hubble flow log hacmidir. Tipik kurumsal göç 4-8 hafta sürer ve bir downtime gerektirmez.
AdminNetworkPolicy ne zaman kullanılmalı?
Kubernetes 1.32 ile stable hale gelen AdminNetworkPolicy (ANP) ve BaselineAdminNetworkPolicy (BANP), cluster-admin’in tüm namespace’leri kapsayan kuralları namespace sahibinden bağımsız uygulamasını mümkün kılar. Çok kiracılı kümelerde “hiçbir kiracı kube-system’in dışına çıkamaz” veya “tüm namespace’lerde varsayılan deny” gibi global politikalar için ideal yaklaşımdır. Cilium CCNP ile kıyaslandığında ANP CNI-bağımsızdır; ancak Cilium CCNP’nin L7 ve FQDN yetenekleri ANP’de yoktur. Olgun kurulumlar her ikisini birleşik kullanır.
Sonuç: Zero Trust Mikrosegmentasyonun Verdikti
Kubernetes NetworkPolicy ve mikrosegmentasyon, modern bulut yerel uygulamalarda zero trust güvenliğin temel taşıdır ve artık opsiyonel değildir. CNCF 2025 verisinin gösterdiği gibi üretim kümelerinin üçte ikisi hâlâ allow-all modda çalışırken ihlallerin %47’si yatay hareketten kaynaklanıyor; bu denklem yalnızca mikrosegmentasyonla kapatılabilir. Standart NetworkPolicy v1 temel L3/L4 koruma sağlarken Cilium ile eBPF tabanlı veri düzlemi L7 görünürlüğü, FQDN egress, kimlik tabanlı politikalar ve Hubble observability gibi gelişmiş yetenekler getiriyor; Kubernetes 1.32 ile gelen AdminNetworkPolicy ise cluster-admin için global kontrol sağlıyor. Verdikt: Yeni kümeleri Cilium üzerinde Dataplane-V2 veya BYO kurmak, mevcut kümelere ise NSA/CISA Hardening Guide ile uyumlu kademeli default-deny ve audit→enforce geçişi uygulamak 2026’nın sektör standardıdır. Konuyu daha geniş kümede tamamlamak için Zero Trust Mimarisi rehberi, Container Güvenliği, DevSecOps Shift-Left ve SBOM ve SLSA içerikleri tamamlayıcıdır; Kubernetes operasyonu için Docker ve Kubernetes Yönetimi rehberi ile Cloud-Native Mimari 2026 best practices belgesini birlikte okumanızı öneririm. Otorite kaynaklar için Cilium dokümantasyonu, Calico dokümantasyonu, Kubernetes NetworkPolicy spec, NSA/CISA Kubernetes Hardening Guide, CNCF Blog, Isovalent Blog, eBPF.io ve Hubble GitHub sayfalarını inceleyebilirsiniz.
Ömer ÖNAL
Mayıs 16, 2026Yazılım danışmanlığı projelerinde sıkça karşılaştığım bir soru: “Hangi mimari hangi senaryoda öncelikli olmalı?” Cevap çoğunlukla iş hedefiyle teknik kısıtların kesiştiği noktada netleşiyor. Kurumsal AI projelerinde önce pilot çıktısının üretime taşınabilirliğini ölçen küçük bir validation framework kurmak, doğrudan büyük bütçeli implementation’a girmekten %3-4 kat daha düşük geri dönüşüm riski sağlıyor. Yorumlarınıza açığım.