Cilium ile Kubernetes Ağ Politikalarını Aşamalı Sıkılaştırma

Kubernetes ortamlarında ağ politikası uygulamak herkesin kabul ettiği doğru yaklaşımdır; ama birçok ekip üretimde kırılma yaratmaktan çekindiği için bu işi sürekli erteler. Sonuçta cluster büyür, servisler çoğalır ve doğu-batı trafik görünmez bir serbest alana dönüşür. Cilium, gözlemlenebilirlik ve politika uygulamayı aynı zeminde birleştirdiği için bu geçişi daha kontrollü hâle getirir. Doğru sıra izlendiğinde, “her şeyi bir gecede kapatmak” yerine adım adım sıkılaştırma mümkündür.

Neden aşamalı yaklaşım şart?

Cluster üzerinde hangi pod’un hangi servise konuştuğu net bilinmeden doğrudan deny mantığına geçmek, özellikle eski servislerde üretim hatası doğurur. Bu yüzden ilk amaç “engellemek” değil, mevcut davranışı görünür kılmaktır.

Sağlıklı geçiş üç evrede düşünülür:

1. Trafiği ve bağımlılıkları gözlemleme
2. Namespace veya uygulama bazında izin modelini tanımlama
3. Kademeli olarak zorunlu politika moduna geçme

Bu sıra, güvenlik ile operasyon arasında gereksiz çatışmayı azaltır.

Başlangıç envanteri nasıl çıkarılır?

Önce hangi servislerin gerçekten birbirine ihtiyaç duyduğunu anlamalısınız. Bu aşamada:

• ingress ve egress yönlerini ayırın
• DNS, metrics, tracing, secret yönetimi gibi ortak servisleri not alın
• batch işleri ve cron workload’larını ayrı değerlendirin
• geçici debug pod’larının politikasız davranmasını engelleyin

Cilium Hubble veya eşdeğer görünürlük araçları, tam bu noktada değer üretir. Amaç sadece bağlantı sayısı görmek değil, uygulama sahipliğini de anlamaktır.

Politika yazımında hangi prensipler işe yarar?

İlk kural setini en dar etki alanında başlatmak doğrudur. Örneğin tek bir namespace veya tek bir uygulama etrafında başlayın. Politika yazarken şu yaklaşım işleri kolaylaştırır:

• Ortak platform servisleri için ayrı politika grubu oluşturun.
• Uygulama içi trafik ile namespace dışı trafiği ayrı tanımlayın.
• DNS ve observability bağımlılıklarını açıkça izin listesine koyun.
• matchLabels kullanımında ekip standardını koruyun.

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: payments-api-egress
spec:
  endpointSelector:
    matchLabels:
      app: payments-api
  egress:
    - toEndpoints:
        - matchLabels:
            app: postgres

Kademeli zorlama nasıl yapılır?

Pratikte şu akış güvenli sonuç verir:

1. Seçili namespace’lerde sadece görünürlük toplayın.
2. Tavsiye edilen politika setini oluşturun.
3. Düşük riskli servislerde kuralı etkinleştirin.
4. Olay ve drop kayıtlarını gözleyin.
5. Üretim kritik namespace’lere kontrollü geçiş yapın.

Bu modelde geri dönüş yolu nettir ve değişiklik pencereleri daha yönetilebilir olur.

Dikkat edilmesi gereken operasyonel noktalar

• Uygulama etiketleri dağınıksa politika sürdürülemez.
• Namespace sınırları yanlış tasarlandıysa politika sayısı patlar.
• Politika ihlallerini sadece güvenlik ekibi değil platform ekibi de izlemelidir.
• GitOps hattına bağlanmayan ağ politikaları kısa sürede manuel istisna deposuna döner.

Kısacası konu yalnızca YAML yazmak değildir; cluster sözleşmesini disipline etmektir.

Sonuç

Cilium ile ağ politikası sıkılaştırması, Kubernetes güvenliğini teoriden pratiğe taşıyan güçlü bir adımdır. Başarının anahtarı agresif başlangıç değil, görünürlükten zorunlu kontrole giden aşamalı bir yol izlemektir. Servis bağımlılıklarını doğru modellediğinizde hem güvenlik seviyesini yükseltir hem de üretim riskini yönetilebilir tutarsınız.