DOKS ve Ağ Güvenliği Neden Önemli?

Bulut tabanlı Kubernetes kümelerinde, özellikle DigitalOcean Kubernetes (DOKS) gibi yönetilen servislerde, uygulamalarınızın güvenliğini sağlamak kritik öneme sahiptir. Geleneksel ağ politikaları genellikle yetersiz kalırken, Cilium’un sunduğu gelişmiş yetenekler, mikroservisler arası iletişimi detaylı bir şekilde kontrol etmenizi ve ağ güvenliğinizi bir üst seviyeye taşımanızı sağlar. Bu makale, DOKS ortamında Cilium ile nasıl gelişmiş ağ politikaları oluşturacağınızı, uygulayacağınızı ve bu sayede altyapınızın direncini artıracağınızı adım adım açıklayacaktır.

DOKS ve Ağ Güvenliği Neden Önemli?

Günümüzün hızla değişen dijital dünyasında, uygulamalar giderek daha karmaşık hale geliyor ve genellikle mikroservis mimarileri kullanılarak geliştiriliyor. Bu mikroservisler, farklı işlevleri yerine getiren bağımsız birimler olarak çalışır ve birbirleriyle ağ üzerinden iletişim kurarlar. DigitalOcean Kubernetes (DOKS), bu tür modern uygulamaları dağıtmak ve yönetmek için popüler, yönetilen bir platform sunar. Ancak, bu esneklik ve ölçeklenebilirlik beraberinde ciddi ağ güvenliği zorluklarını da getirir. Her bir mikroservisin kendi içinde veya dış dünyayla nasıl iletişim kurduğunu kontrol etmek, potansiyel güvenlik açıklarını kapatmak ve veri sızıntılarını önlemek için hayati bir gerekliliktir. Geleneksel güvenlik duvarları veya sanal ağ yapılandırmaları, dinamik ve geçici Kubernetes podları için yeterince esnek veya granüler olmayabilir. Bu nedenle, Kubernetes içinde doğrudan entegre olabilen ve pod seviyesinde detaylı kontrol sağlayabilen gelişmiş bir ağ politika motoruna ihtiyaç duyulur. Bu motor, uygulamanızın her katmanında güvenlik sağlamanın anahtarıdır.

DOKS gibi yönetilen bir Kubernetes hizmetinde çalışırken, altyapının bir kısmı DigitalOcean tarafından yönetilse de, uygulamalarınızın ağ trafiğini denetleme ve güvence altına alma sorumluluğu genellikle size aittir. Bu, yalnızca dışarıdan gelen kötü niyetli saldırıları engellemekle kalmaz, aynı zamanda içeriden kaynaklanabilecek yetkisiz erişimi veya yanlamasına hareketleri (lateral movement) de sınırlar. Örneğin, bir mikroservisinizin ele geçirilmesi durumunda, bu servisin yalnızca belirli diğer servislere veya veri tabanlarına erişimine izin vererek potansiyel hasarı minimize edebilirsiniz. Bu “en az ayrıcalık” (least privilege) prensibini ağ düzeyinde uygulamak, genel güvenlik duruşunuzu önemli ölçüde güçlendirir. Ayrıca, uyumluluk gereksinimlerini (örneğin GDPR, HIPAA) karşılamak için ağ trafiğinin belirli kurallara göre izlenmesi ve denetlenmesi gerekebilir. İşte bu noktada, Kubernetes’in yerleşik ağ politikalarını aşan, daha güçlü ve esnek bir çözüm olan Cilium devreye girer. Cilium, eBPF (extended Berkeley Packet Filter) teknolojisini kullanarak Linux çekirdeği düzeyinde ağ ve güvenlik operasyonları gerçekleştirir, bu da ona olağanüstü performans ve detaylı kontrol yeteneği kazandırır.

Cilium Nedir ve Neden Tercih Edilmeli?

Cilium, Kubernetes kümeleri için tasarlanmış açık kaynaklı bir Cloud Native Computing Foundation (CNCF) projesi ve güçlü bir Container Network Interface (CNI) eklentisidir. Temel amacı, mikroservis tabanlı uygulamalar için ağ bağlantısı, gözlemlenebilirlik ve güvenlik sağlamaktır. Geleneksel CNI çözümlerinden farklı olarak Cilium, Linux çekirdeğindeki eBPF (extended Berkeley Packet Filter) teknolojisini kullanarak çalışır. eBPF, çekirdek düzeyinde güvenli ve programlanabilir bir veri yolu sağlar, bu da Cilium’a inanılmaz performans, esneklik ve detaylı kontrol yeteneği kazandırır. Bu sayede, ağ paketlerini çekirdek düzeyinde filtreleyebilir, yönlendirebilir ve manipüle edebilir, bu da geleneksel iptables tabanlı çözümlerden çok daha verimli ve güçlüdür.

Cilium’u tercih etmenin başlıca nedenleri şunlardır:

• Yüksek Performans: eBPF sayesinde, ağ trafiği kullanıcı alanına (userspace) taşınmadan doğrudan çekirdek düzeyinde işlenir. Bu, gecikmeyi azaltır ve verimliği artırır, özellikle yüksek performans gerektiren mikroservis ortamlarında büyük avantaj sağlar.
• Uygulama Katmanı (L7) Politikaları: Geleneksel Kubernetes Network Policy’ler yalnızca Layer 3 (IP adresi) ve Layer 4 (TCP/UDP port) seviyesinde kontrol sağlarken, Cilium HTTP, gRPC gibi Layer 7 protokollerine kadar inerek daha granüler politikalar yazmanıza olanak tanır. Bu sayede, belirli HTTP yollarını veya metotlarını engelleyebilir, API çağrılarını denetleyebilirsiniz.
• Kimlik Tabanlı Güvenlik: Cilium, IP adresleri yerine pod kimliklerini (Kubernetes servis hesapları, etiketler) kullanarak politikaları uygular. Bu, pod’lar yeniden başlatıldığında veya IP adresleri değiştiğinde bile politikaların tutarlı kalmasını sağlar, bu da dinamik Kubernetes ortamları için kritik öneme sahiptir.
• Gözlemlenebilirlik (Observability): Cilium, ağ trafiğini detaylı bir şekilde izlemek için Hubble adında entegre bir araç sunar. Hubble, ağ akışlarını görselleştirmenize, güvenlik olaylarını tespit etmenize ve sorunları gidermenize yardımcı olan güçlü bir gözlemlenebilirlik platformudur.
• Dış Dünya Entegrasyonu: Cilium, Kubernetes kümesi dışındaki hizmetlerle (örneğin, bulut sağlayıcının yönetilen veritabanları veya harici API’ler) güvenli ve kontrollü bir şekilde iletişim kurmak için gelişmiş yetenekler sunar.
• Güvenlik ve İzolasyon: Her bir mikroservisin yalnızca ihtiyaç duyduğu kaynaklara erişimini sağlayarak “en az ayrıcalık” ilkesini ağ düzeyinde uygular. Bu, bir güvenlik ihlali durumunda etki alanını sınırlar ve yanlamasına hareketleri (lateral movement) zorlaştırır.

Bu özellikler, özellikle DOKS gibi yönetilen Kubernetes ortamlarında, güvenlik ve operasyonel verimlilik açısından Cilium’u cazip bir seçenek haline getirir. Mikroservislerinizin ağ trafiğini tam kontrol altında tutmak ve geleceğe dönük, güvenli bir altyapı oluşturmak istiyorsanız, Cilium güçlü bir araçtır.

Temel Kubernetes Ağ Politikaları Nasıl Çalışır ve Sınırları Nelerdir?

Kubernetes, uygulamalarınızın ağ trafiğini denetlemek için yerleşik bir mekanizma sunar: Kubernetes Network Policies. Bu politikalar, pod’lar arasındaki ve pod’lar ile dış dünya arasındaki ağ iletişimini kontrol etmenizi sağlar. Temel olarak, bir güvenlik duvarı kuralı gibi çalışırlar, belirli pod’ların diğer pod’larla veya belirli IP aralıklarıyla hangi portlar üzerinden iletişim kurabileceğini tanımlarsınız. Network Policy’ler, Kubernetes API’si aracılığıyla bir YAML dosyası olarak tanımlanır ve kümedeki CNI eklentisi tarafından uygulanır (örneğin, Calico, Flannel veya Cilium).

Bir Kubernetes Network Policy genellikle şu bileşenleri içerir:

• podSelector: Politikanın uygulanacağı pod’ları seçer. Bu, etiketler (labels) kullanılarak yapılır.
• policyTypes: Politikanın hangi trafik türlerini etkileyeceğini belirtir: Ingress (gelen trafik), Egress (giden trafik) veya her ikisi.
• ingress kuralları: Seçilen pod’lara gelen trafiği tanımlar. Kimden gelebileceği (from) ve hangi portlardan (ports) gelebileceği belirtilir.
• egress kuralları: Seçilen pod’lardan giden trafiği tanımlar. Kimlere gidebileceği (to) ve hangi portlardan (ports) gidebileceği belirtilir.

Örneğin, yalnızca belirli bir frontend pod’unun backend pod’una 8080 portundan erişmesine izin veren temel bir Network Policy şöyle görünebilir:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

Bu politika, app: backend etiketine sahip pod’lara yalnızca app: frontend etiketine sahip pod’lardan gelen ve 8080 portunu kullanan TCP trafiğine izin verir. Diğer tüm gelen trafik engellenir. Ancak, bu temel Network Policy’lerin bazı önemli sınırlamaları vardır:

• Katman 3/4 Sınırlaması: Yalnızca IP adresi ve port seviyesinde kontrol sağlarlar (Layer 3 ve Layer 4). HTTP yolları, metotları veya gRPC servisleri gibi uygulama katmanı (Layer 7) kontrolleri yapamazlar. Bu, mikroservisler arası API erişimini detaylı bir şekilde denetlemek isteyen modern uygulamalar için büyük bir eksikliktir.
• Kimlik Tabanlı Olmaması: Politikalar genellikle IP adresleri veya pod etiketleri üzerinden uygulanır. Pod’ların IP adresleri dinamik olarak değişebilir ve etiketler bazen belirli bir servisin kimliğini tam olarak yansıtmayabilir. Daha sağlam bir güvenlik modeli için, servis hesapları veya diğer kimlik mekanizmaları üzerinden politikaların uygulanması daha güvenlidir.
• Gözlemlenebilirlik Eksikliği: Kubernetes Network Policy’ler uygulandığında, hangi trafiğin engellendiğini veya izin verildiğini anlamak zordur. Ağ akışlarının görselleştirilmesi veya güvenlik olaylarının gerçek zamanlı olarak izlenmesi için ek araçlara ihtiyaç duyulur.
• Dış Dünya Kontrolü: Küme dışındaki kaynaklara (örneğin, harici veritabanları, API’ler) giden trafiği kontrol etmek için daha az esneklik sunarlar. Genellikle CIDR bloklarına dayalı basit kurallarla sınırlıdırlar.

Bu sınırlamalar, özellikle karmaşık ve yüksek güvenlik gerektiren mikroservis mimarilerinde, daha gelişmiş bir ağ politika çözümüne olan ihtiyacı ortaya koyar. İşte tam da bu noktada Cilium’un sunduğu ek yetenekler devreye girer ve temel Kubernetes Network Policy’lerinin ötesine geçerek çok daha güçlü bir güvenlik katmanı sağlar.

Cilium Ağ Politikalarına Derinlemesine Bakış: Gelişmiş Yetenekler Neler?

Cilium, standart Kubernetes Network Policy’lerinin ötesine geçerek, CiliumNetworkPolicy (CNP) ve CiliumClusterwideNetworkPolicy (CCNP) gibi özel kaynak tanımları (CRD’ler) aracılığıyla çok daha zengin ve esnek ağ güvenlik kuralları sunar. Bu gelişmiş yetenekler, özellikle dinamik ve güvenlik odaklı mikroservis ortamları için tasarlanmıştır. Cilium’un temel güçlerinden biri, eBPF’in sağladığı çekirdek düzeyindeki programlanabilirlik sayesinde, geleneksel ağ politikalarının ulaşamadığı detay seviyelerine inebilmesidir.

Cilium Ağ Politikalarının sunduğu başlıca gelişmiş yetenekler şunlardır:

1. Uygulama Katmanı (L7) Politikaları:

   Bu, Cilium’un en önemli yeteneklerinden biridir. Standart politikalar yalnızca IP ve port bazında çalışırken, Cilium HTTP, gRPC, Kafka gibi uygulama katmanı protokollerini anlayabilir ve bu protokollere dayalı kurallar uygulayabilir. Örneğin, bir backend servisine gelen HTTP trafiğinde yalnızca GET /api/v1/users isteğine izin verip POST /api/v1/admin isteğini engelleyebilirsiniz. Bu, API ağ geçitlerinde veya servis ağlarında uygulanan güvenlik kontrollerini doğrudan ağ katmanına taşımanızı sağlar.

   
   apiVersion: "cilium.io/v2"
   kind: CiliumNetworkPolicy
   metadata:
     name: allow-get-users
     namespace: default
   spec:
     endpointSelector:
       matchLabels:
         app: backend
     ingress:
     - fromEndpoints:
       - matchLabels:
           app: frontend
       toPorts:
       - ports:
         - port: "8080"
           protocol: TCP
         rules:
           http:
           - method: "GET"
             path: "/api/v1/users"
   

   Bu örnek, backend pod’una yalnızca frontend pod’undan gelen ve /api/v1/users yoluna yapılan GET isteklerine izin verir. Diğer tüm HTTP istekleri engellenir.

2. Kimlik Tabanlı Güvenlik:

   Cilium, pod’ların IP adresleri yerine Kubernetes etiketleri ve servis hesaplarına dayalı kimlikler atar. Bu kimlikler, pod’lar yeniden başlatıldığında veya IP adresleri değiştiğinde bile tutarlılığını korur. Politikaları bu kimlikler üzerinden tanımlamak, dinamik Kubernetes ortamlarında çok daha güvenilir ve yönetilebilir bir yaklaşım sunar. Örneğin, “bu servis hesabı kimliğine sahip tüm pod’lar şu diğer servis hesabı kimliğine sahip pod’larla iletişim kurabilir” şeklinde kurallar yazabilirsiniz.

3. Dış Dünya Kontrolü (Egress Gateway ve DNS Politikaları):

   Cilium, küme dışına giden trafiği kontrol etmek için gelişmiş seçenekler sunar. toCIDR veya toEntities gibi kurallarla belirli IP aralıklarına veya önceden tanımlanmış dış varlıklara (örneğin, host, world, cluster) erişimi kısıtlayabilirsiniz. En önemlisi, DNS tabanlı politikalarla belirli alan adlarına erişime izin verebilirsiniz. Bu, bir uygulamanın yalnızca api.example.com adresine istek göndermesine izin verip diğer tüm dış bağlantıları engellemenizi sağlar. Bu, özellikle hassas verilerin yanlışlıkla dışarı sızmasını önlemek için çok güçlü bir mekanizmadır.

   
   apiVersion: "cilium.io/v2"
   kind: CiliumNetworkPolicy
   metadata:
     name: allow-egress-to-example-api
     namespace: default
   spec:
     endpointSelector:
       matchLabels:
         app: my-service
     egress:
     - toEndpoints:
       - matchLabels:
           k8s:io.kubernetes.pod.namespace: kube-system # Örnek: Kube-DNS'e erişim
       toPorts:
       - ports:
         - port: "53"
           protocol: UDP
         - port: "53"
           protocol: TCP
       toFQDNs:
       - matchName: "api.example.com" # Sadece bu alan adına giden trafiğe izin ver
       ports:
       - port: "443"
         protocol: TCP
   

   Bu politika, my-service pod’unun yalnızca api.example.com adresine (DNS üzerinden çözümlenerek) 443 portundan giden trafiğe izin verir ve DNS sorguları için de kube-system namespace’indeki DNS servislerine erişimi sağlar.

4. Gözlemlenebilirlik ve Sorun Giderme (Hubble):

   Cilium’un entegre gözlemlenebilirlik katmanı Hubble, ağ trafiği akışlarını gerçek zamanlı olarak izlemenizi, görselleştirmenizi ve sorunları gidermenizi sağlar. Hubble UI veya CLI aracılığıyla hangi pod’ların kiminle konuştuğunu, hangi politikaların uygulandığını ve hangi trafiğin engellendiğini kolayca görebilirsiniz. Bu, güvenlik olaylarını tespit etmek ve ağ sorunlarını hızla çözmek için paha biçilmez bir araçtır.

5. Güvenli Hizmet Mesh Entegrasyonu:

   Cilium, Istio gibi servis mesh çözümleriyle entegre olabilir ve servis mesh’in ağ katmanındaki güvenlik politikalarını eBPF aracılığıyla daha verimli bir şekilde uygulayabilir. Bu, servis mesh’in sunduğu L7 kontrolünü, Cilium’un yüksek performanslı eBPF veri yoluyla birleştirir.

Bu gelişmiş yetenekler, DOKS ortamında mikroservislerinizin ağ güvenliğini sadece bir güvenlik duvarı olmaktan çıkarıp, uygulama katmanına kadar uzanan akıllı ve proaktif bir güvenlik sistemi haline getirir. Cilium ile, “kim kiminle hangi protokolle ve hangi veriye erişebilir” sorusuna çok daha detaylı ve güvenilir cevaplar verebilirsiniz.

DOKS Üzerinde Cilium Kurulumu ve Temel Yapılandırma Adımları

DigitalOcean Kubernetes (DOKS) üzerinde Cilium’u etkinleştirmek, kümenizin ağ yeteneklerini ve güvenlik duruşunu önemli ölçüde geliştirecektir. DOKS, yeni bir küme oluştururken doğrudan Cilium CNI’yi seçme seçeneği sunar, bu da kurulum sürecini oldukça basitleştirir. Mevcut bir kümede Cilium’u etkinleştirmek biraz daha karmaşık olabilir, çünkü bu, mevcut CNI’nizi değiştirmeyi ve potansiyel olarak kümedeki tüm pod’ların yeniden başlatılmasını gerektirir. Ancak, sıfırdan bir DOKS kümesi kurarken Cilium’u seçmek en sorunsuz yöntemdir.

Yeni Bir DOKS Kümesinde Cilium Kurulumu

Yeni bir DOKS kümesi oluştururken, DigitalOcean kontrol panelinde veya doctl CLI aracıyla CNI seçeneğini “Cilium” olarak belirlemeniz yeterlidir. İşte adım adım süreç:

1. DigitalOcean Kontrol Paneli Üzerinden:
   • DigitalOcean hesabınıza giriş yapın.
   • Sol menüden “Kubernetes”e gidin ve “Create a Kubernetes Cluster” düğmesine tıklayın.
   • Küme yapılandırma adımlarını takip edin (Bölge, Sürüm, Node Pool’lar vb.).
   • “Networking” veya “Advanced Options” bölümünde “Container Network Interface (CNI)” seçeneğini göreceksiniz. Burada “Cilium”u seçin.
   • Kümenizi oluşturmayı tamamlayın. DigitalOcean, Cilium’u sizin için otomatik olarak kuracak ve yapılandıracaktır.
2. doctl CLI Üzerinden:

   doctl kullanıyorsanız, --cni bayrağını cilium olarak ayarlayabilirsiniz:

   
   doctl kubernetes cluster create <cluster-adı> \
     --region nyc1 \
     --version 1.28.2-do.0 \
     --node-pool name=worker-pool,size=s-2vcpu-4gb,count=3 \
     --cni cilium
   

   Bu komut, Cilium CNI ile yeni bir DOKS kümesi oluşturacaktır.

Mevcut Bir DOKS Kümesinde Cilium Kurulumu (Dikkat Gerektirir!)

Mevcut bir DOKS kümesinde CNI değiştirmek, dikkatli planlama ve kesinti potansiyeli nedeniyle genellikle önerilmez. Ancak, yine de yapmak isterseniz, genellikle mevcut CNI’yi kaldırmanız ve ardından Cilium’u yüklemeniz gerekir. Bu işlem, kümenizin ağ bağlantısını geçici olarak kesebilir ve tüm pod’ların yeniden başlatılmasını gerektirebilir. Bu nedenle, bu işlemi üretim ortamlarında yapmadan önce mutlaka bir test ortamında denemeniz ve yedeklemelerinizi almanız şiddetle tavsiye edilir. Genellikle, bu senaryoda yeni bir küme oluşturup uygulamalarınızı oraya taşımak daha güvenli ve kolay bir yöntemdir.

Temel Cilium Yapılandırma Kontrolü

Cilium kurulduktan sonra, durumunu kontrol etmek önemlidir. Aşağıdaki komutlarla Cilium pod’larının çalışır durumda olduğundan emin olabilirsiniz:

kubectl get pods -n kube-system -l k8s-app=cilium

Tüm Cilium pod’larının Running durumunda olması gerekir. Ayrıca, Cilium’un durumunu kontrol etmek için Cilium CLI’ı kullanabilirsiniz:

cilium status

Eğer cilium CLI yüklü değilse, Cilium belgelerinden nasıl yükleneceğini öğrenebilirsiniz.

Temel bir CiliumNetworkPolicy‘yi test etmek için, tüm pod’lar arası trafiği engelleyen ve sadece belirli bir servise erişime izin veren bir politika uygulayabilirsiniz. Örneğin, tüm pod’lardan giden trafiği engelleyen bir politika:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: deny-all-egress
  namespace: default
spec:
  endpointSelector: {} # Tüm pod'ları seçer
  egress: [] # Hiçbir giden trafiğe izin verme

Bu politikayı uyguladıktan sonra, pod’larınızın dışarıya veya birbirine erişmeye çalıştığında başarısız olduğunu göreceksiniz. Ardından, belirli erişimlere izin veren daha spesifik politikalar ekleyerek ağınızı kademeli olarak açabilirsiniz. Bu, “varsayılan olarak reddet, özel olarak izin ver” (deny-by-default, allow-by-exception) güvenlik modelini uygulamanın temel adımıdır.

Cilium’un DOKS üzerinde başarılı bir şekilde çalışması, ileri düzey ağ politikalarını uygulamanız için sağlam bir temel oluşturur. Bu kurulum adımlarının ardından, artık mikroservislerinizin ağ güvenliğini daha detaylı bir şekilde kontrol etmeye hazırsınız.

Gerçek Dünya Senaryosu: Mikroservis İzolasyonu ve Dış Erişim Kontrolü

Modern bir e-ticaret uygulamasını ele alalım. Bu uygulama genellikle frontend (müşteri arayüzü), backend-api (ürün, sipariş yönetimi), payment-service (ödeme işlemleri) ve database (veri depolama) gibi mikroservislerden oluşur. Bu servislerin her birinin kendine özgü iletişim ihtiyaçları ve güvenlik gereksinimleri vardır. Cilium ile bu servisler arasında sıkı bir izolasyon sağlayabilir ve dış dünya ile olan etkileşimlerini detaylı bir şekilde kontrol edebiliriz.

Vaka Analizi: E-ticaret Uygulamasında Güvenlik

Senaryomuzda, aşağıdaki güvenlik hedeflerine ulaşmak istiyoruz:

1. frontend sadece backend-api servisine erişebilir.
2. backend-api sadece payment-service ve database servislerine erişebilir.
3. payment-service, yalnızca belirli bir harici ödeme ağ geçidi API’sine (örneğin, api.paymentgateway.com) TLS (443 portu) üzerinden erişebilir.
4. database servisine dışarıdan hiçbir şekilde erişilemez, sadece backend-api erişebilir.
5. Hiçbir servis, tanımlanan kurallar dışında dış dünyaya erişemez.

Adım 1: Varsayılan Olarak Tüm Trafiği Engelleme (Deny-by-Default)

İlk olarak, tüm pod’lardan gelen ve giden trafiği engelleyen genel bir politika uygulayarak güvenlik duruşumuzu güçlendiririz. Bu, “varsayılan olarak reddet” prensibini uygulamamızı sağlar.

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: deny-all-ingress-egress
  namespace: default
spec:
  endpointSelector: {} # Tüm pod'ları seçer
  ingress: [] # Tüm gelen trafiği engelle
  egress: []  # Tüm giden trafiği engelle (DNS trafiği için istisna gerekebilir)

Bu politika, kube-system namespace’indeki DNS pod’larına giden trafiği de engelleyecektir. Bu nedenle, küme içindeki DNS trafiğine izin veren bir kural eklememiz gerekir:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: allow-kube-dns
  namespace: default
spec:
  endpointSelector: {} # Tüm pod'ları seçer
  egress:
  - toEndpoints:
    - matchLabels:
        k8s:io.kubernetes.pod.namespace: kube-system # Kube-DNS'in bulunduğu namespace
        k8s:k8s-app: kube-dns # Kube-DNS pod'larının etiketi
    ports:
    - port: "53"
      protocol: UDP
    - port: "53"
      protocol: TCP

Bu iki politika birlikte, sadece DNS sorgularına izin verirken diğer tüm trafiği varsayılan olarak engeller.

Adım 2: Mikroservisler Arası İletişim Kuralları

Şimdi, servisler arası gerekli iletişimi açan politikaları tanımlayalım:

Frontend’den Backend-API’ye Erişim:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: allow-frontend-to-backend-api
  namespace: default
spec:
  endpointSelector:
    matchLabels:
      app: backend-api
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080" # Backend-API'nin dinlediği port
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/products/*"
        - method: "POST"
          path: "/orders"

Bu politika, backend-api servisine sadece frontend servisinden gelen ve belirli HTTP yollarını ve metotlarını içeren trafiğe izin verir.

Backend-API’den Payment-Service ve Database’e Erişim:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: allow-backend-api-egress
  namespace: default
spec:
  endpointSelector:
    matchLabels:
      app: backend-api
  egress:
  - toEndpoints:
    - matchLabels:
        app: payment-service
    ports:
    - port: "8081" # Payment-Service'in dinlediği port
      protocol: TCP
  - toEndpoints:
    - matchLabels:
        app: database
    ports:
    - port: "5432" # PostgreSQL varsayımı
      protocol: TCP

Bu politika, backend-api‘nin payment-service‘e 8081 portundan ve database‘e 5432 portundan erişmesine izin verir.

Adım 3: Harici Ödeme Ağ Geçidine Erişim Kontrolü

payment-service‘in yalnızca belirli bir harici ödeme ağ geçidine erişmesine izin verelim:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: allow-payment-service-to-gateway
  namespace: default
spec:
  endpointSelector:
    matchLabels:
      app: payment-service
  egress:
  - toFQDNs:
    - matchName: "api.paymentgateway.com"
    ports:
    - port: "443"
      protocol: TCP

Bu politika, payment-service pod’larının yalnızca api.paymentgateway.com alan adına 443 portu (HTTPS) üzerinden giden trafiğe izin verir. Diğer tüm dış bağlantılar engellenir.

Adım 4: Veritabanı İzolasyonu

database servisi için gelen trafiği sadece backend-api‘den gelecek şekilde kısıtladık (yukarıdaki allow-backend-api-egress politikasının bir parçası olarak). Ayrıca, database pod’unun dışarıya herhangi bir bağlantı kurmasını engellemek için ayrı bir egress politikası tanımlayabiliriz (eğer genel deny-all-egress politikası yoksa veya daha spesifik bir kural isteniyorsa):

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: deny-database-egress
  namespace: default
spec:
  endpointSelector:
    matchLabels:
      app: database
  egress:
  - toEndpoints:
    - matchLabels:
        k8s:io.kubernetes.pod.namespace: kube-system # Kube-DNS'e erişim için
        k8s:k8s-app: kube-dns
    ports:
    - port: "53"
      protocol: UDP
    - port: "53"
      protocol: TCP
  # Diğer tüm giden trafik engellenir, sadece DNS'e izin verilir

Bu kapsamlı politika seti, e-ticaret uygulamamızdaki mikroservisler arasında sıkı bir güvenlik duvarı oluşturur. Her servisin sadece ihtiyaç duyduğu kaynaklarla iletişim kurmasını sağlayarak, potansiyel güvenlik ihlallerinin etkisini minimize eder ve hassas verilerin korunmasına yardımcı olur. Cilium’un L7 ve FQDN tabanlı politikaları sayesinde, bu izolasyon çok daha granüler ve etkili bir şekilde gerçekleştirilebilir.

İleri Düzey Cilium Özellikleri: Hubble ve Ağ Gözlemi

Cilium’un gücü sadece gelişmiş ağ politikaları yazmakla sınırlı değildir; aynı zamanda bu politikaların nasıl çalıştığını ve ağ trafiğinin küme içinde nasıl aktığını anlamak için güçlü gözlemlenebilirlik araçları da sunar. Bu araçların başında Hubble gelir. Hubble, Cilium’un eBPF tabanlı veri yolundan elde ettiği ağ akışı verilerini toplayan, depolayan ve görselleştiren bir gözlemlenebilirlik platformudur. Ağınızdaki her türlü iletişimi gerçek zamanlı olarak izlemenizi, güvenlik olaylarını tespit etmenizi ve sorunları gidermenizi sağlar.

Hubble Nedir ve Neden Kullanmalıyız?

Hubble, eBPF’in sağladığı çekirdek düzeyindeki ağ olaylarını yakalayarak, pod’lar arası, pod’lardan dış dünyaya ve dış dünyadan pod’lara olan tüm ağ trafiğini kaydeder. Bu veriler, hangi pod’un kiminle, hangi protokolle ve hangi porttan konuştuğunu gösterir. Hubble’ın sunduğu temel yetenekler şunlardır:

• Gerçek Zamanlı Ağ Akışı İzleme: Ağınızdaki her paketin yolculuğunu, hangi politikanın izin verdiğini veya engellediğini anlık olarak görebilirsiniz.
• Görselleştirme: Hubble UI, ağ trafiğini grafiksel olarak gösterir. Bu, karmaşık mikroservis mimarilerinde bağımlılıkları ve iletişim yollarını anlamayı kolaylaştırır.
• Politika Geliştirme ve Doğrulama: Yeni bir politika uyguladığınızda, Hubble aracılığıyla bu politikanın beklediğiniz gibi çalışıp çalışmadığını, hangi trafiği etkilediğini veya yanlışlıkla engellediğini hızlıca doğrulayabilirsiniz.
• Sorun Giderme: Bir uygulamanın neden diğerine erişemediğini veya bir dış hizmetle neden iletişim kuramadığını anlamak için Hubble, ağ sorunlarını teşhis etmede paha biçilmez bilgiler sunar.
• Güvenlik Olayı Tespiti: Yetkisiz erişim denemeleri, şüpheli ağ kalıpları veya politika ihlalleri gibi güvenlik olaylarını anında tespit etmenizi sağlar.

Hubble Kurulumu ve Kullanımı

Cilium’u DOKS üzerinde kurarken Hubble’ı da etkinleştirebilirsiniz. Genellikle, Cilium CLI ile Hubble’ı kurmak en kolay yoldur:

cilium hubble enable

Bu komut, Hubble Relay ve Hubble UI’yi kümenize dağıtır. Kurulum tamamlandıktan sonra, Hubble UI’ye erişmek için bir port iletme (port-forward) işlemi yapmanız gerekebilir:

cilium hubble ui

Bu komut, yerel tarayıcınızda Hubble UI’yi açacak ve kümenizdeki ağ trafiğini görselleştirmenizi sağlayacaktır. Hubble CLI ile de doğrudan komut satırından ağ akışlarını sorgulayabilirsiniz:

# Tüm ağ akışlarını izle
hubble observe

# Belirli bir namespace'deki akışları izle
hubble observe -n default

# Belirli bir pod'dan giden akışları izle
hubble observe --follow --pod frontend

# Engellenen akışları göster
hubble observe --type drop

Hubble, özellikle karmaşık politikalar uygularken veya bir güvenlik ihlali durumunda neyin yanlış gittiğini anlamak istediğinizde size büyük avantaj sağlar. Ağınızdaki “görünürlük” seviyesini artırarak, proaktif güvenlik ve daha hızlı sorun giderme yetenekleri kazanırsınız.

Cilium’un Diğer İleri Düzey Özellikleri

• Egress Gateway: Belirli pod’lardan gelen tüm dış trafiği belirli bir düğüm (node) veya IP adresi üzerinden yönlendirmenizi sağlar. Bu, dışarıya giden trafiği tek bir noktadan denetlemek ve sabit bir çıkış IP adresi sağlamak istediğiniz senaryolarda kullanışlıdır.
• Bandwidth Management: eBPF’in trafiği çekirdek düzeyinde yönetme yeteneğini kullanarak, pod’lara veya hizmetlere bant genişliği limitleri uygulayabilirsiniz. Bu, kaynak izolasyonu ve hizmet kalitesi (QoS) için önemlidir.
• Transparent Encryption: IPsec veya WireGuard kullanarak pod’lar arası trafiği şifrelemenizi sağlar. Bu, hassas verilerin ağ üzerinde güvenli bir şekilde iletilmesini garanti eder.
• Service Mesh Entegrasyonu: Istio gibi servis mesh’lerle derin entegrasyonlar sunar. Cilium, servis mesh’in L7 politikalarını eBPF ile daha verimli bir şekilde uygulayabilir, bu da performans artışı ve daha tutarlı bir güvenlik duruşu sağlar.

Bu ileri düzey özellikler, Cilium’u DOKS gibi modern Kubernetes platformlarında sadece bir CNI olmaktan çıkarıp, kapsamlı bir ağ ve güvenlik çözümüne dönüştürür. Özellikle büyük ve karmaşık altyapılarda, bu yetenekler operasyonel yükü azaltırken güvenlik ve gözlemlenebilirlik seviyesini artırır.

Sonuç: Güvenli ve Ölçeklenebilir Ağ Yönetimi İçin Cilium

DigitalOcean Kubernetes (DOKS) ortamında mikroservis tabanlı uygulamaların güvenliğini sağlamak, basit IP ve port bazlı ağ politikalarının ötesinde, daha granüler ve esnek çözümler gerektirir. Bu makalede ele aldığımız gibi, Cilium, eBPF teknolojisinin gücünü kullanarak bu ihtiyacı fazlasıyla karşılayan, ileri düzey bir Container Network Interface (CNI) çözümüdür. Cilium’un sunduğu uygulama katmanı (L7) politikaları, kimlik tabanlı güvenlik, DNS tabanlı dış erişim kontrolü ve entegre gözlemlenebilirlik (Hubble) gibi özellikler, geleneksel Kubernetes ağ politikalarının sınırlamalarını aşarak, modern bulut yerel uygulamalar için sağlam bir güvenlik katmanı oluşturur.

DOKS üzerinde Cilium’u etkinleştirerek, mikroservisleriniz arasındaki iletişimi en ince ayrıntısına kadar kontrol edebilir, “en az ayrıcalık” prensibini ağ düzeyinde uygulayabilir ve potansiyel güvenlik ihlallerinin etki alanını önemli ölçüde sınırlayabilirsiniz. Gerçek dünya senaryolarında gösterdiğimiz gibi, bir e-ticaret uygulamasının farklı servisleri arasında sıkı izolasyon sağlamak ve harici API’lere kontrollü erişim sağlamak, Cilium ile kolayca ve etkin bir şekilde yönetilebilir. Ayrıca, Hubble’ın sağladığı derinlemesine görünürlük sayesinde, ağ trafiğini izleyebilir, güvenlik olaylarını tespit edebilir ve sorunları hızla giderebilirsiniz. Bu, sadece güvenliği artırmakla kalmaz, aynı zamanda operasyonel verimliliği de yükseltir.

Özetle, DOKS üzerinde Cilium kullanmak, Kubernetes ağ güvenliğinizi geleceğe hazırlamanın ve uygulamalarınızın hem performanslı hem de güvenli bir şekilde çalışmasını sağlamanın anahtarıdır. Mikroservislerinizin karmaşıklığı arttıkça ve güvenlik tehditleri geliştikçe, Cilium gibi ileri düzey bir çözüm, altyapınızın direncini ve uyumluluğunu sürdürmek için vazgeçilmez bir araç haline gelecektir.

Sıkça Sorulan Sorular

1. Cilium’u mevcut bir DOKS kümesinde etkinleştirebilir miyim?

   Evet, teknik olarak mümkündür ancak dikkatli planlama ve potansiyel kesinti riskleri içerir. Mevcut CNI’nizin kaldırılması ve Cilium’un kurulması genellikle tüm pod’ların yeniden başlatılmasını gerektirir. Üretim ortamlarında bu işlem yerine yeni bir Cilium özellikli küme oluşturup uygulamaları taşımak daha güvenli ve önerilen bir yaklaşımdır.

2. Cilium ile standart Kubernetes Network Policy’leri birlikte kullanabilir miyim?

   Evet, Cilium hem kendi CiliumNetworkPolicy (CNP) ve CiliumClusterwideNetworkPolicy (CCNP) kaynaklarını hem de standart Kubernetes NetworkPolicy kaynaklarını destekler ve uygular. Bu, geçiş süreçlerinde veya farklı ekiplerin farklı politika türlerini kullanması durumunda esneklik sağlar.

3. Cilium, eBPF kullanmanın performans avantajları nelerdir?

   eBPF, ağ paketlerini Linux çekirdeği düzeyinde, kullanıcı alanına taşımadan işler. Bu, geleneksel iptables tabanlı çözümlere kıyasla önemli ölçüde daha düşük gecikme ve daha yüksek verim sağlar. Ayrıca, eBPF programları dinamik olarak yüklenebilir ve çalıştırılabilir, bu da Cilium’a olağanüstü esneklik ve programlanabilirlik kazandırır.

4. Hubble nedir ve neden önemlidir?

   Hubble, Cilium’un entegre gözlemlenebilirlik platformudur. eBPF aracılığıyla yakalanan ağ akışı verilerini görselleştirmenizi, izlemenizi ve analiz etmenizi sağlar. Hangi pod’ların kiminle konuştuğunu, hangi politikaların uygulandığını ve hangi trafiğin engellendiğini gerçek zamanlı olarak görmenizi sağlayarak, ağ sorunlarını gidermede ve güvenlik olaylarını tespit etmede kritik bir rol oynar.

5. Cilium, Service Mesh (örneğin Istio) ile birlikte kullanılabilir mi?

   Kesinlikle. Cilium, Istio gibi servis mesh çözümleriyle uyumlu çalışır ve hatta onların ağ katmanındaki yeteneklerini güçlendirebilir. Cilium, servis mesh’in L7 politikalarını eBPF ile daha verimli bir şekilde uygulayabilir, bu da daha iyi performans ve daha tutarlı bir güvenlik duruşu sağlar. Cilium, servis mesh’in veri düzlemi olarak da işlev görebilir.