Network Security

Kubernetes üzerinde yüzlerce hatta binlerce container'ı birden fazla node üzerinde koşturduğunuz bir senaryoda, sistem güvenliği artık bir seçenek değil, kritik bir zorunluluktur. Sistemdeki tek bir zafiyet, bir anda tüm workload'larınıza sıçrayabilir, hassas verilerinizi sızdırabilir veya hizmetlerinizi tamamen durdurabilir.

Bir Kubernetes cluster'ını devasa ve çok hareketli bir plaza gibi düşünebilirsiniz. İçeri kimin gireceği, içerideki odalar (yani pod'lar) arasında kimin dolaşabileceği ve konuşmaların dinlenip dinlenmediği sıkı kurallara bağlı olmalıdır.

Bu yazıda, Kubernetes güvenlik duruşunuzu (security posture) güçlendirecek 5 temel stratejiyi, sıfırdan ve en pratik haliyle inceleyeceğiz.

1. Şifreleme ve SSL Otomasyonu (cert-manager & Let's Encrypt)

Dış dünyadan cluster'ınıza gelen trafiğin (HTTPS) şifrelenmiş olması şarttır. Ancak sertifikaları manuel olarak oluşturmak, takip etmek ve süresi dolmadan yenilemek bir kabustur. İşte burada işi otomatize etmemiz gerekiyor.

• Let's Encrypt: Bize ücretsiz ve güvenilir SSL/TLS sertifikaları sağlayan servistir (ACME protokolü üzerinden çalışır).

• cert-manager: Kubernetes içinde çalışan ve Let's Encrypt ile konuşarak sertifika alma/yenileme işlerini (CRD'ler kullanarak) sizin yerinize yapan bir "robot"tur.

Aşağıdaki örnekte, cert-manager'a "Benim için Let's Encrypt üzerinden sertifika al" diyen bir ClusterIssuer ve Certificate konfigürasyonu görüyoruz:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: [email protected]
    privateKeySecretRef:
      name: letsencrypt-prod-key
    solvers:
    - http01:
        ingress:
          class: traefik
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: example-com-tls
spec:
  secretName: example-com-tls
  dnsNames:
  - example.com
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer

Bu yapı sayesinde sertifikanız Kubernetes Secret objesi olarak saklanır ve süresi dolmaya yakınken cert-manager tarafından otomatik olarak yenilenir. Gece rahat uyursunuz!

💡 İpucu: cert-manager'ı deploy etmeden önce HTTP-01 veya DNS-01 doğrulamaları (challenge) için DNS kayıtlarınızın doğru ayarlandığından emin olun.

---

2. Ingress Güvenliği

Ingress, cluster'ınızın ana kapısıdır. Dışarıdan gelen HTTP/HTTPS isteklerini alır ve içerideki doğru servise yönlendirir. Bu ana kapının güvenli ve şifreli olması gerekir.

Popüler bir Ingress Controller olan Traefik, cert-manager ve Let's Encrypt ile kusursuz bir uyum içinde çalışır. Aşağıdaki konfigürasyon (IngressRoute), gelen trafiği nasıl güvenli bir şekilde karşılayıp içerideki uygulamaya ileteceğini gösterir:

apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute # Traefik'in gelen trafiği yönlendirme kuralı.
metadata:
  name: secure-web
  annotations:
    # Otomasyon: Bu kural için otomatik olarak geçerli bir SSL sertifikası üret.
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  entryPoints:
    - websecure # Sadece şifrelenmiş (HTTPS) kapıdan gelen istekleri kabul et.
  routes:
    - match: Host(`app.example.com`) # Eğer kullanıcı tam olarak bu adrese geliyorsa...
      kind: Rule
      services:
        - name: web # ...isteği cluster içindeki "web" isimli Service'e...
          port: 80  # ...80 portundan teslim et.
  tls:
    # HTTPS şifrelemesi için kullanılacak sertifikanın tutulduğu Secret objesi.
    secretName: example-com-tls

Burada Traefik, arka planda sertifika taleplerini cert-manager'a devreder. Manuel hiçbir müdahaleye gerek kalmadan HTTPS aktif hale gelir.

---

3. CNI Network Policies

Ana kapıyı (Ingress) kilitledik diyelim, peki ya içerisi? Kubernetes'te varsayılan olarak tüm pod'lar birbiriyle konuşabilir. Bu çok tehlikelidir! Eğer bir frontend pod'u zafiyet barındırıyorsa, saldırgan rahatlıkla database pod'una sızabilir (buna yatay hareket / lateral movement denir).

Bunu engellemek için NetworkPolicy kullanırız.

🗺️ Pod İletişimi Topolojisi

Aşağıdaki senaryoyu hayal edelim: Sadece Frontend'in Web'e erişmesini istiyoruz. Diğer her şeyi engelleyeceğiz.

       [ İnternet ]
            │
            ▼ 
      [ Frontend Pod ]
            │
            │  ✅ İZİN VERİLDİ (Network Policy)
            ▼
         [ Web Pod ]

Örnek Standart NetworkPolicy YAML: (Sadece 'frontend' etiketine sahip pod'ların, 'web' etiketine sahip pod'lara 80 portundan erişmesine izin verir)

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-frontend
spec:
  podSelector:
    matchLabels:
      role: web
  ingress:
    - from:
        - podSelector:
            matchLabels:
              role: frontend
      ports:
        - protocol: TCP
          port: 80

Cilium ile Gelişmiş Politikalar

Güvenliği işletim sistemi çekirdeği (kernel) seviyesine indirmek isterseniz, eBPF teknolojisini kullanan Cilium harika bir CNI alternatifidir. Cilium ile çok daha zengin politikalar yazabilirsiniz:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-frontend-to-web
spec:
  endpointSelector:
    matchLabels:
      role: web
  ingress:
    - fromEndpoints:
        - matchLabels:
            role: frontend
      toPorts:
        - ports:
            - port: "80"
              protocol: TCP

---

4. Mutual TLS (mTLS) - Karşılıklı Güven

Standart TLS/SSL'de sadece istemci (client) sunucunun (server) kimliğini doğrular.

mTLS (Mutual TLS) ise iki yönlüdür. Cluster içinde A servisi B servisiyle konuşmak istediğinde, her iki taraf da veriyi takas etmeden önce birbirinin kimliğini doğrular. Bu iki yönlü kimlik doğrulama, araya girme (man-in-the-middle) saldırılarını tamamen ortadan kaldırır.

⚠️ Dikkat: Süresi dolan veya yanlış yapılandırılan sertifikalar mTLS bağlantılarını anında bozar. Sertifika yaşam döngülerini mutlaka izleyin ve yenilemeleri otomatikleştirin.

---

5. Hubble ile Gözlemlenebilirlik

Güvenlikte altın bir kural vardır: Göremediğiniz bir şeyi koruyamazsınız. Ağınızda hangi pod hangisiyle konuşuyor? Sistemde olağandışı bir durum var mı?

Eğer Cilium kullanıyorsanız, onunla entegre çalışan Hubble size ağ akışları (network flows), uygulama performansı ve güvenlik olayları hakkında çok derin bir görünürlük sağlar.

Pratik CLI Kullanımı:

Öncelikle cluster'ınıza Cilium ve Hubble'ı kurmanız (deploy etmeniz) gerekir. Aşağıdaki komutlarla kurulumu yapıp canlı trafiği izlemeye hemen başlayabilirsiniz:

# 1. Cilium'u Hubble ile birlikte cluster'a hızlıca deploy edelim
kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/v1.12/install/kubernetes/quick-install.yaml

# 2. Hubble metrics sunucusunu aktifleştirelim
cilium hubble enable

# 3. Sadece 'default' namespace içindeki canlı ağ akışını (network flows) izleyelim
hubble observe --namespace default

Bu sayede trafiğinizi saniye saniye takip edebilir, hataları (troubleshooting) çok daha hızlı çözebilirsiniz.