Kubernetes'te Sıfır Güvenlik: Doğu-Batı Trafiğini Güvence Altına Alma

Geleneksel çevre tabanlı güvenlik modeli, modern bulut yerel ortamlarda geçersiz hale gelmiştir. Bir Kubernetes kümesinde, iş yükleri geçici, dinamik ve sürekli ölçeklenir. Sadece kenardaki güvenlik duvarlarına güvenmek, kötü niyetli aktörlerin çevreyi aştığında yetersiz kalır. İşte burada Sıfır Güvenlik Ağ Erişimi (ZTNA) kritik hale gelir. Özellikle, küme içindeki podlar arasındaki iletişim olan doğu-batı trafiğini güvence altına almak, varsayılan güven yerine açık doğrulama gerektirir.

Bu kılavuz, yerel Ağ Politikaları ve Kimlik Bilinçli Vekiller (IAP) kullanarak Kubernetes'te ZTNA ilkelerini nasıl uygulayacağınızı incelemektedir. Basit "tümünü izin ver" kurallarının ötesine geçerek, kökeni ne olursa olsun her hizmet çağrısının kimlik doğrulamasının ve yetkilendirmesinin yapıldığı bir model kuracağız.

Doğu-Batı Trafiğinin Zorluğu

Monolitik mimaride, her şey aynı güvenilen ağda yaşandığı için doğu-batı trafiği genellikle göz ardı edilir. Ancak Kubernetes'te tek bir podun ele geçirilmesi, bir saldırganın kümede tarama yapmasına ve kritik veritabanlarına veya yönetim arayüzlerine yan yana hareket etmesine olanak tanır. Katı segmentasyon olmadan, bir ihlalin patlama yarıçapı önemli ölçüde büyüktür. ZTNA, hiçbir podun kimlik tarafından açıkça izin verilmedikçe başka bir podla konuşamayacağını sağlayarak bu sorunu çözer, sadece IP adresine göre değil.

Katman 1: Ayrıntılı Ağ Politikaları

Savunmanın ilk katmanı Kubernetes NetworkPolicy'dir. Bu yerel kaynaklar, podlar arası iletişim için kurallar tanımlamanıza olanak tanır. Standart ağ politikaları kendi başlarına kimlik bilincine sahip olmasa da (pod etiketleri ve ad alanlarına dayanırlar), Sıfır Güvenlik mimarimizin iskeletini oluştururlar. Varsayılan olarak, her ad alanı için "tümünü engelle" giriş politikası uygulamanız gerekir.

Örneğin, bir ön uç uygulamasının bir arka uç API ile iletişim kurması gerektiğini, ancak başka hiçbir hizmetin API'ye erişmemesi gerektiğini düşünün. Bu, podları etiketleyip özel bir giriş kuralı uygulayarak elde edilebilir.

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

Bu örnekte, aynı ad alanında `app: frontend-app` etiketine sahip podlar, 8080 portunda arka uca erişebilir. Diğer tüm trafik, CNI (Container Network Interface) eklentisi tarafından düşürülerek katı segmentasyon sağlanır.

Katman 2: Kimlik Bilinçli Vekiller

Ağ Politikaları trafiğin *nerede* gidebileceğini kontrol ederken, ZTNA kimin *istekte bulunduğunu* kontrol etmeyi gerektirir. İşte burada Kimlik Bilinçli Vekil (IAP) devreye girer. Bir IAP, bağlantıya izin vermeden önce çağrı yapanın kimliğini doğrulayan istemciler ile hizmetler arasında yer alır. Kubernetes bağlamında bu, genellikle JWT tokenlarını veya OAuth2 kimlik bilgilerini doğrulayan bir service mesh (örneğin Istio) veya özel bir yan kılıf vekili kullanmayı içerir.

Her pod'a bir yan kılıf vekili enjekte ederek, isteklerin geçerli kimlik doğrulama tokenları taşımasını sağlayabilirsiniz. Geçerli bir token taşımayan bir istek varsa, vekil bağlantıyı hemen sonlandırır, böylece saldırgan Ağ Politikasını (örneğin bir konteyner kaçışı yoluyla) atlasa bile yan yana hareketi engellenir.

Service Mesh ile Kimliğin Uygulanması

Bir service mesh kullanmak, kimlik doğrulamasını uygulama kodunuzdan yükümlülükten kurtarmanızı sağlar. Gelen isteklerin konusunu, izin verilen kimliklerin listesine karşı kontrol eden AuthorizationPolicies tanımlayabilirsiniz.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-oidc
  namespace: production
spec:
  selector:
    matchLabels:
      app: backend-api
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/production/sa/frontend-sa"]

Bu politika, üretim ad alanında yalnızca `frontend-sa` (Service Account)'ın arka uca çağrı yapmasına izin verir. Harici bir IP trafiği taklit etmeye çalışsa bile, kimlik doğrulaması başarısız olacaktır.

Hepsini Bir Araya Getirmek

Kubernetes'te etkili ZTNA, Ağ Politikaları ile Kimlik Bilinçli Vekiller arasında seçim yapmak değildir; bunları katmanlaştırmaktır. Ağ Politikaları, saldırı yüzeyini sınırlamak için gerekli ağ segmentasyonunu sağlarken, IAP bu segmentler üzerinden geçen trafiğin kimlik doğrulamasının ve yetkilendirmesinin yapılmasını sağlar.

Bunu uygularken, güvenliğin iteratif olduğunu unutmayın. Trafik akışınızı anlamak için önce bir "tümünü engelle" politikası etkinleştirin, ardından kademeli olarak izin kuralları ekleyin. Eş zamanlı olarak, kimlik doğrulamasını tanıtmak için bir service mesh veya yan kılıf desenine geçiş yapın. Bu stratejileri birleştirerek, mikro hizmetlerinizi en karmaşık tehditlere karşı koruyan sağlam bir derinlikte savunma mimarisi oluşturursunuz.

Sıfır Güvenlik benimsemek bir yolculuktur, ancak buluttaki modern, dinamik uygulamaları güvence altına almanın tek uygulanabilir yoludur.