Kubernetes Podlar Arası Network Policies Savaşları: Güvenliği…

Kubernetes Podlar Arası Network Policies Savaşları: Güvenliği Sağlama Rehberi

Kubernetes, konteynerleştirilmiş uygulamaları yönetmek için güçlü bir platformdur. Ancak, bu gücün beraberinde getirdiği karmaşıklık, güvenlik endişelerini de beraberinde getirir. Özellikle podlar arasındaki ağ trafiğini kontrol etmek, modern uygulamaların güvenliği için kritik bir öneme sahiptir. İşte tam bu noktada Kubernetes Podlar Arası Network Policies devreye girer. Bu rehberde, Network Policies’in ne olduğunu, neden önemli olduğunu ve nasıl kullanılacağını detaylı bir şekilde inceleyeceğiz.

Bu yazıda, Kubernetes’teki ağ güvenliğinin temellerini atacağız. Uygulamalarınızın hassas verilerini korumak ve yetkisiz erişimi engellemek için Network Policies’i bir kalkan olarak nasıl kullanabileceğinizi öğreneceksiniz. Hazırsanız, bu “savaş” alanına dalalım ve podlarınızın güvenliğini en üst düzeye çıkaralım.

Network Policies Nedir ve Neden Önemlidir?

Kubernetes’te Network Policies, podlar arasındaki ağ iletişimini hangi trafiğin izinli olacağını tanımlayan kurallardır. Varsayılan olarak, bir Kubernetes kümesindeki tüm podlar birbirleriyle serbestçe iletişim kurabilir. Bu durum, özellikle büyük ve karmaşık sistemlerde ciddi güvenlik açıklarına yol açabilir. Bir podun ele geçirilmesi durumunda, saldırganın küme içindeki diğer podlara kolayca yayılmasına olanak tanır.

Network Policies, bu varsayılan “açık” politikayı değiştirerek “kapalı” bir duruma getirir. Yani, hiçbir trafik varsayılan olarak izinli değildir. Sadece Network Policy ile açıkça izin verilen trafik akışları gerçekleşebilir. Bu, “least privilege” (en az ayrıcalık) prensibini ağ katmanında uygulamanın en etkili yollarından biridir. Böylece, sadece gerekli olan iletişimlere izin vererek saldırı yüzeyini önemli ölçüde azaltmış olursunuz.

Network Policies Nasıl Çalışır?

Network Policies, Kubernetes API nesneleri olarak tanımlanır ve bir ağ politikası (NetworkPolicy) kaynağıdır. Bu politikalar, belirli etiketlere (labels) sahip podlara uygulanır. Bir pod, kendisine atanan etiketlerle eşleşen tüm Network Policy kurallarına uyar. Bir Network Policy, hangi podların bir hedef podla iletişim kurmasına izin verildiğini (ingress) ve hedef podun hangi dış varlıklarla iletişim kurmasına izin verildiğini (egress) tanımlayabilir.

Politikalar, IP blokları, pod etiketleri veya ad alanları (namespaces) gibi farklı seçiciler (selectors) kullanarak trafiği filtreleyebilir. Örneğin, bir podun yalnızca aynı ad alanındaki başka bir podla veya belirli bir IP aralığındaki sunucularla iletişim kurmasına izin veren kurallar oluşturabilirsiniz. Bu esneklik, karmaşık ağ yapılandırmalarını bile yönetmenizi sağlar.

Bir pod üzerinde birden fazla Network Policy tanımlanabilir. Eğer bir pod birden fazla politikaya dahil oluyorsa, bu politikaların tümünün izin verdiği trafik akışlarına izin verilir. Eğer bir pod hiçbir Network Policy tarafından hedeflenmiyorsa, varsayılan olarak tüm ağ trafiğine izin verilir (bu nedenle, güvenlik için politikaları dikkatli bir şekilde yapılandırmak önemlidir).

Temel Network Policy Yapılandırmaları

Şimdi, pratik örneklere geçelim. Bir Kubernetes kümesinde Network Policies’i nasıl uygulayacağımızı görelim. Başlamadan önce, kümenizde bir Network Policy sağlayıcısının (Network Policy Provider) kurulu olduğundan emin olmanız gerekir. Popüler seçenekler arasında Calico, Cilium ve Weave Net bulunur. Bu sağlayıcılar, Network Policy API’sini yorumlar ve podlar arasındaki trafiği uygular.

İlk olarak, basit bir “deny-all” (her şeyi reddet) politikası oluşturalım. Bu politika, hangi trafiğin izinli olacağını açıkça belirtmediğimiz tüm podlara uygulanacaktır. Bu, başlangıç için güvenli bir noktadır. Ardından, belirli bir pod setine iletişim izni vereceğiz.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: default
spec:
  podSelector: {} # Boş podSelector, bu politikayı namespace'deki tüm podlara uygular
  policyTypes:
  - Ingress
  - Egress

Yukarıdaki default-deny-all politikası, default ad alanındaki tüm podlar için hem gelen (ingress) hem de giden (egress) trafiği reddeder. podSelector: {} ifadesi, bu politikayı ad alanındaki tüm podlara uygulayacağını belirtir. policyTypes alanı ise, bu politikanın hem gelen hem de giden trafiği kapsadığını gösterir.

Gelen Trafiği Kısıtlama (Ingress Policies)

Gelen trafiği kısıtlamak, uygulamanızın yetkisiz dış erişimlere karşı korunmasını sağlamak için hayati önem taşır. Bir podun yalnızca belirli diğer podlardan veya IP adreslerinden trafik almasına izin verebiliriz.

Örneğin, bir frontend podunun yalnızca backend podlarından gelen isteklere yanıt vermesini istediğimizi varsayalım.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-from-backend
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: frontend # Bu politika 'frontend' etiketli podlara uygulanacak
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend # 'backend' etiketli podlardan gelen trafiğe izin ver

Bu politika, app: frontend etiketine sahip podlara uygulanır. Yalnızca app: backend etiketine sahip podlardan gelen gelen trafiğe izin verir. Bu, frontend podunun backend podları dışındaki herhangi bir kaynaktan gelen isteklere yanıt vermeyeceği anlamına gelir.

Giden Trafiği Kısıtlama (Egress Policies)

Giden trafiği kısıtlamak da en az gelen trafiği kısıtlamak kadar önemlidir. Bu, bir podun yalnızca belirli dış hizmetlere veya küme içindeki diğer podlara bağlanmasına izin vermek anlamına gelir. Bu, bir pod ele geçirildiğinde saldırganın küme dışındaki sistemlere sızmasını engellemeye yardımcı olur.

Örneğin, bir backend podunun yalnızca bir harici veritabanına (belirli bir IP adresi aralığında) ve kendi ad alanındaki frontend podlarına bağlanmasına izin vermek isteyebiliriz.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend-egress
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: backend # Bu politika 'backend' etiketli podlara uygulanacak
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 192.168.10.0/24 # Belirli bir IP aralığına izin ver
    ports:
    - protocol: TCP
      port: 5432
  - to:
    - podSelector:
        matchLabels:
          app: frontend # Kendi ad alanındaki 'frontend' podlarına izin ver

Bu politika, app: backend etiketine sahip podlar için giden trafiği kontrol eder. 192.168.10.0/24 IP bloğundaki TCP port 5432’ye (örneğin bir PostgreSQL veritabanı) ve aynı ad alanındaki app: frontend etiketli podlara giden trafiğe izin verir. Diğer tüm giden trafik varsayılan olarak reddedilir.

Ad Alanları Arası İletişim (Cross-Namespace Communication)

Network Policies, aynı ad alanındaki podlar arasındaki iletişimi kontrol etmekle kalmaz, aynı zamanda farklı ad alanları arasındaki iletişimi de yönetebilir. Bu, mikroservis mimarilerinde farklı servislerin hangi ad alanlarındaki diğer servislere erişebileceğini belirlemek için kullanışlıdır.

Bir api-gateway podunun, users ad alanındaki user-service poduna ve products ad alanındaki product-service poduna bağlanmasına izin vermek istediğimizi düşünelim.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-gateway-egress
  namespace: api # Bu politika 'api' ad alanındaki podlara uygulanacak
spec:
  podSelector:
    matchLabels:
      app: api-gateway
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          name: users # 'users' ad alanını seç
      podSelector:
        matchLabels:
          app: user-service # 'user-service' podunu seç
  - to:
    - namespaceSelector:
        matchLabels:
          name: products # 'products' ad alanını seç
      podSelector:
        matchLabels:
          app: product-service # 'product-service' podunu seç

Bu politika, api ad alanındaki app: api-gateway etiketli podun, users ad alanındaki app: user-service poduna ve products ad alanındaki app: product-service poduna giden trafiğe izin verir. namespaceSelector kullanarak belirli ad alanlarını hedefleyebiliriz.

Network Policy Sağlayıcıları ve Entegrasyonu

Daha önce de belirtildiği gibi, Network Policies’in çalışması için kümenizde bir Network Policy sağlayıcısının (CNI plugin’i) yüklü olması gerekir. Bu sağlayıcılar, Kubernetes API’sini dinler ve Network Policy nesnelerini yorumlayarak podlar arasındaki trafiği filtrelemek için ağ kurallarını uygular.

Yaygın Network Policy sağlayıcılarından bazıları şunlardır:

Calico: Yüksek performanslı ve ölçeklenebilir bir ağ çözümüdür. Network Policy desteği güçlüdür.
Cilium: eBPF (extended Berkeley Packet Filter) teknolojisini kullanarak gelişmiş ağ ve güvenlik özellikleri sunar. Network Policy’leri eBPF ile verimli bir şekilde uygular.
Weave Net: Kolay kurulumu ve kullanımı ile bilinir. Network Policy desteği sunar.

Seçtiğiniz sağlayıcıyı kümenize kurduktan sonra, Network Policy nesnelerinizi oluşturmaya başlayabilirsiniz. Her sağlayıcının kendine özgü bazı ek özellikleri veya yapılandırma seçenekleri olabilir, bu nedenle kullandığınız sağlayıcının belgelerini incelemeniz önemlidir.

Yaygın Hatalar ve Dikkat Edilmesi Gerekenler

Kubernetes Podlar Arası Network Policies yapılandırırken dikkat edilmesi gereken bazı yaygın hatalar ve noktalar vardır:

Politikasız Podlar: Varsayılan olarak, bir pod üzerinde hiçbir Network Policy tanımlanmamışsa, tüm trafiğe izin verilir. Bu, güvenlik için istenmeyen bir durumdur. Bu nedenle, tüm podlarınızın en azından bir “deny-all” politikası tarafından kapsandığından emin olun.
Yanlış Etiket Seçiciler: Politikaların podlara veya ad alanlarına doğru şekilde uygulanması için etiket seçicilerin (label selectors) doğru kullanılması kritik öneme sahiptir. Etiketlerin yanlış yazılması veya eksik olması, politikaların beklendiği gibi çalışmamasına neden olabilir.
Eksik policyTypes: Bir Network Policy’de policyTypes alanı belirtilmezse, varsayılan olarak hem Ingress hem de Egress trafiğine izin verilir. Bu, politikayı etkisiz hale getirebilir. Her zaman hangi trafik türünü kontrol etmek istediğinizi açıkça belirtin.
NamespaceSelector’ın Yanlış Kullanımı: Ad alanları arası iletişimde namespaceSelector kullanırken, hedef ad alanında doğru etiketlerin olduğundan emin olun.
Test Edilmeyen Politikalar: Ağ politikalarını canlı ortama uygulamadan önce mutlaka test edin. Yanlış yapılandırılmış bir politika, uygulamanızın kritik bileşenlerinin birbirleriyle iletişim kurmasını engelleyebilir ve hizmet kesintilerine yol açabilir.

Sonuç: Ağ Güvenliğinde Bir Adım Önde

Kubernetes Podlar Arası Network Policies, konteynerleştirilmiş uygulamalarınızın güvenliğini sağlamak için güçlü ve esnek bir araçtır. Uygulamalarınızın ağ trafiğini yöneterek, yetkisiz erişimi engelleyebilir ve saldırı yüzeyini önemli ölçüde azaltabilirsiniz. “Least privilege” prensibini ağ katmanında uygulayarak, sistemlerinizin daha güvenli ve dayanıklı olmasını sağlayabilirsiniz.

Bu rehberde, Network Policies’in temel kavramlarını, nasıl yapılandırılacağını ve yaygın kullanım senaryolarını inceledik. Unutmayın ki, en iyi güvenlik stratejisi, sürekli bir iyileştirme ve dikkatli yapılandırma gerektirir. Network Policies’i etkin bir şekilde kullanarak Kubernetes ortamınızda ağ güvenliğini bir üst seviyeye taşıyabilirsiniz. Artık “savaş” alanında daha donanımlısınız!

Umarım bu detaylı rehber, Kubernetes ağ güvenliği konusundaki bilginizi artırmıştır. Mustafa Erbay’ın blogunda daha fazla teknoloji ve kariyer içeriği için bizi takip etmeye devam edin!

Kubernetes Podlar Arası Network Policies Savaşları: Güvenliği…