Kubernetes’te Çok Kiracılı Ortam ve Güvenlik Temelleri

Modern bulut tabanlı uygulamaların hızla yaygınlaşmasıyla birlikte, şirketler genellikle aynı Kubernetes kümesi üzerinde farklı ekiplerin veya uygulamaların bir arada barındırılması ihtiyacıyla karşılaşıyor. Peki, bu karmaşık yapıyı yönetirken kaynakları nasıl adil dağıtabilir, ekipler arası izolasyonu nasıl sağlayabilir ve güvenlik risklerini en aza indirebiliriz? Bu makalede, Kubernetes’in sunduğu güçlü araçlar olan Namespaces, Resource Quotas, NetworkPolicies ve Pod Security Admission mekanizmalarını kullanarak çok kiracılı (multi-tenancy) bir ortamda sağlam bir güvenlik temeli oluşturmanın inceliklerini adım adım keşfedeceğiz. Amacımız, hem yeni başlayanların konuyu temelden anlamasını sağlamak hem de deneyimli kullanıcılar için pratik ipuçları sunmaktır.

Çok kiracılı ortam (multi-tenancy), tek bir altyapı kümesi üzerinde birden fazla müşteri, ekip veya uygulama örneğinin aynı anda barındırılması anlamına gelir. Kubernetes bağlamında, bu durum genellikle farklı departmanların (örneğin, geliştirme, test, üretim), farklı projelerin veya hatta farklı dış müşterilerin aynı Kubernetes kümesini paylaşması şeklinde karşımıza çıkar. Bu yaklaşımın temel amacı, donanım kaynaklarının daha verimli kullanılması, operasyonel maliyetlerin düşürülmesi ve yönetim yükünün azaltılmasıdır. Ancak bu avantajlarla birlikte, ciddi güvenlik ve kaynak yönetimi zorluklarını da beraberinde getirir. Bir kiracının (tenant) kaynakları aşırı tüketmesi diğer kiracıların performansını etkileyebilirken, güvenlik ihlalleri bir kiracıdan diğerine sıçrayarak domino etkisi yaratabilir. Bu nedenle, çok kiracılı bir ortamda güçlü bir izolasyon ve güvenlik stratejisi hayati önem taşır.

Güvenlik perspektifinden bakıldığında, çok kiracılı yapılar kendi içinde bir risk barındırır. Kiracılar arası veri sızıntısı, yetkisiz erişim veya kaynak tüketimindeki dengesizlikler, iş sürekliliğini ve veri gizliliğini tehlikeye atabilir. Özellikle birden fazla ekibin aynı kümede çalıştığı büyük kuruluşlarda, her ekibin kendi izolasyonuna ve güvenlik politikalarına sahip olması kritik öneme sahiptir. Bu, sadece kaynak tahsisiyle sınırlı kalmayıp, ağ erişim kontrollerinden pod’ların çalışma zamanı güvenlik ayarlarına kadar geniş bir yelpazeyi kapsar. Örneğin, bir geliştirme ekibinin test amaçlı oluşturduğu zayıf bir yapılandırma, bir üretim ortamına sızarak ciddi sonuçlar doğurabilir. İşte tam da bu noktada, Kubernetes’in sunduğu yerleşik güvenlik ve izolasyon mekanizmaları devreye girer. Bu mekanizmalar sayesinde, her kiracı kendi “sandbox” içinde çalışır ve diğer kiracılar üzerinde istenmeyen bir etki yaratması engellenir. Kaynakların adil dağıtılması ve güvenlik duvarlarının doğru bir şekilde inşa edilmesi, çok kiracılı bir Kubernetes kümesinin omurgasını oluşturur. Bu makalenin ilerleyen bölümlerinde, bu mekanizmaların her birini derinlemesine inceleyecek ve pratik örneklerle nasıl uygulandıklarını göstereceğiz. Böylece, kuruluşlar güvenli ve verimli çok kiracılı Kubernetes ortamları oluşturabilirler.

Kubernetes Namespace’leri ile Mantıksal İzolasyon Nasıl Sağlanır?

Kubernetes’te çok kiracılı bir ortam oluşturmanın ilk ve en temel adımı, Namespaces (isim uzayları) kullanmaktır. Namespaces, Kubernetes kümesi içindeki kaynakları (Pod’lar, Servisler, Deployments, vb.) mantıksal olarak bölümlere ayırmak için kullanılan bir mekanizmadır. Her Namespace, kendi içinde bağımsız bir sanal küme gibi hareket eder. Bu sayede, farklı ekipler veya uygulamalar, kendi Namespace’leri içinde çalışarak birbirlerinin kaynaklarını doğrudan etkilemez ve isim çakışmalarının önüne geçilir. Örneğin, bir “dev” Namespace’i ile bir “prod” Namespace’i oluşturabilir ve bu iki ortamı birbirinden tamamen ayırabilirsiniz. Bu ayrım, hem yönetim kolaylığı hem de güvenlik açısından büyük avantajlar sunar.

Namespaces, kaynakların kimlik doğrulaması (authentication) ve yetkilendirme (authorization) süreçlerinde de merkezi bir rol oynar. Role-Based Access Control (RBAC) kuralları genellikle Namespace bazında uygulanır. Bu, belirli bir kullanıcının veya hizmet hesabının yalnızca belirli bir Namespace içindeki kaynaklara erişebilmesini veya bunları yönetebilmesini sağlar. Böylece, geliştirme ekibinin sadece kendi “dev” Namespace’indeki kaynakları değiştirmesine izin verirken, üretim Namespace’ine erişimini kısıtlayabilirsiniz. Bu katmanlı güvenlik yaklaşımı, yetkisiz erişim riskini önemli ölçüde azaltır. Örneğin, bir geliştiricinin yanlışlıkla üretim ortamındaki bir veritabanını silmesini engellemek için, ona sadece kendi geliştirme ortamı Namespace’inde yetki tanımlarsınız.

Bir Namespace oluşturmak oldukça basittir. Aşağıdaki YAML tanımı ile “gelistirme” adında yeni bir Namespace oluşturabiliriz:

apiVersion: v1
kind: Namespace
metadata:
  name: gelistirme
    

Bu tanımı kaydettikten sonra, kubectl apply -f gelistirme-namespace.yaml komutu ile uygulayabiliriz. Namespaces'leri listelemek için ise kubectl get namespaces komutunu kullanırız. Mevcut Namespaces'leri kontrol etmek, yeni bir ortam kurarken atılması gereken ilk adımdır. Bir Namespace içindeki Pod'ları veya diğer kaynakları yönetmek için kubectl -n gelistirme get pods gibi komutlar kullanırız. Buradaki -n parametresi, hangi Namespace üzerinde işlem yapacağımızı belirtir. Bu temel izolasyon katmanı, çok kiracılı bir Kubernetes kümesinde düzeni sağlamanın anahtarıdır. Ancak yalnızca Namespaces ile tam bir izolasyon ve kaynak kontrolü sağlanamaz. Bu nedenle, sonraki adımlarda diğer güvenlik mekanizmalarını da devreye alacağız.

Kaynak Kotası (Resource Quotas) ile Kaynak Yönetimi Nasıl Yapılır?

Namespaces ile mantıksal izolasyonu sağladıktan sonra, bir sonraki önemli adım kaynakların adil ve kontrollü bir şekilde dağıtılmasını sağlamaktır. İşte burada Kaynak Kotaları (Resource Quotas) devreye girer. Resource Quotas, bir Namespace içindeki toplam kaynak tüketimine (CPU, bellek, depolama alanı) sınırlar koymanıza olanak tanır. Ayrıca, o Namespace içinde oluşturulabilecek Pod'lar, Servisler veya Persistent Volume Claims (PVC'ler) gibi nesnelerin sayısını da sınırlayabilirsiniz. Bu, bir kiracının veya uygulamanın kümenin tamamını ele geçirmesini (resource starvation) engeller ve diğer kiracılar için performans garanti altına alınmasına yardımcı olur. Örneğin, bir geliştirme ekibinin testleri sırasında aşırı CPU veya bellek tüketmesi, üretim ortamındaki kritik uygulamaları etkilememelidir. Resource Quotas tam da bu senaryolarda kurtarıcı bir rol oynar.

Resource Quotas ile iki ana kategoride sınırlama yapabiliriz:

1. Compute Resources (Hesaplama Kaynakları): CPU ve bellek (memory) limitleri belirleyebilirsiniz. Bu limitler, her bir Pod'un isteyeceği (requests) ve maksimum kullanabileceği (limits) miktarları etkiler. Bu sayede, bir Namespace'e toplamda ne kadar CPU ve bellek tahsis edildiğini kontrol edersiniz.
2. Object Count (Nesne Sayısı): Bir Namespace içinde oluşturulabilecek belirli tipteki Kubernetes nesnelerinin (Pod'lar, ConfigMap'ler, Servisler, PVC'ler, vb.) sayısını sınırlayabilirsiniz. Bu, özellikle kontrolsüz kaynak yaratımını engellemek için kullanışlıdır.

Aşağıda, "gelistirme" Namespace'i için bir Resource Quota tanımı örneği bulunmaktadır. Bu kota, bu Namespace içindeki tüm Pod'ların toplamda 2 CPU çekirdeğini ve 4 GB belleği geçemeyeceğini, ayrıca en fazla 10 Pod ve 5 PVC oluşturulabileceğini belirtir:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: gelistirme-kaynak-kotasi
  namespace: gelistirme
spec:
  hard:
    requests.cpu: "2"
    requests.memory: "4Gi"
    limits.cpu: "4"
    limits.memory: "8Gi"
    pods: "10"
    persistentvolumeclaims: "5"
    

Bu YAML dosyasını kubectl apply -f gelistirme-resource-quota.yaml komutuyla uyguladığımızda, "gelistirme" Namespace'indeki kaynak tüketimi belirtilen sınırlar içinde kalacaktır. Eğer bir Pod oluşturulmak istenir ve bu Pod mevcut kotaları aşarsa, Kubernetes Pod'un oluşturulmasına izin vermeyecek ve bir hata mesajı dönecektir. Bu proaktif kontrol mekanizması, kaynakların adil dağıtımını ve kümenin istikrarını garanti altına almak için vazgeçilmezdir. Özellikle maliyet kontrolü ve performans garantisi sağlamak istediğiniz çok kiracılı ortamlar için Resource Quotas kritik bir rol oynar. Kaynak Kotaları, sadece israfa engel olmakla kalmaz, aynı zamanda her kiracının kaynaklarını önceden planlamasını ve optimize etmesini teşvik eder.

NetworkPolicy'ler ile Ağ Güvenliği Sınırları Nasıl Çizilir?

Namespaces ile mantıksal izolasyonu ve Resource Quotas ile kaynak yönetimini sağladıktan sonra, çok kiracılı bir ortamın güvenlik omurgasını güçlendirmek için en kritik adımlardan biri ağ izolasyonudur. NetworkPolicy'ler, Kubernetes içindeki Pod'ların birbirleriyle ve dış dünya ile nasıl iletişim kurabileceğini tanımlayan kuralları belirlemenizi sağlar. Varsayılan olarak, Kubernetes'te bir NetworkPolicy uygulanmadığı sürece, tüm Pod'lar birbirleriyle serbestçe iletişim kurabilir. Bu durum, özellikle hassas verilerin bulunduğu veya farklı güvenlik seviyelerine sahip uygulamaların aynı kümede barındırıldığı çok kiracılı ortamlarda kabul edilemez bir güvenlik riski oluşturur. NetworkPolicy'ler sayesinde, Pod'lar arasındaki trafiği kontrol altına alabilir, yetkisiz erişimi engelleyebilir ve "en az ayrıcalık" (least privilege) ilkesini ağ katmanında uygulayabilirsiniz.

NetworkPolicy'ler, ingress (içeri gelen) ve egress (dışarı çıkan) trafik kurallarını tanımlamanıza olanak tanır. Bir NetworkPolicy, bir veya daha fazla Pod'u hedefleyebilir ve bu Pod'lara hangi diğer Pod'ların, Namespaces'lerin veya IP adres aralıklarının erişebileceğini (ingress) ya da bu Pod'ların hangi hedeflere erişebileceğini (egress) belirler. Bu esneklik, çok katmanlı bir ağ güvenliği stratejisi oluşturmak için güçlü bir araçtır. Örneğin, bir veritabanı Pod'unun sadece belirli bir uygulama Pod'undan gelen bağlantıları kabul etmesini sağlarken, internete çıkışını tamamen engelleyebilirsiniz. Bu sayede, olası bir güvenlik ihlalinde, saldırganın yanal hareket kabiliyeti kısıtlanmış olur.

Aşağıda, "gelistirme" Namespace'indeki "backend" etiketine sahip Pod'ların sadece "frontend" etiketine sahip Pod'lardan ve aynı Namespace içindeki DNS Pod'larından gelen trafiklere izin veren bir NetworkPolicy örneği bulunmaktadır:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: gelistirme-backend-networkpolicy
  namespace: gelistirme
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system # DNS için gerekli
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0 # Tüm dışarı çıkışa izin ver (opsiyonel, kısıtlanabilir)
    ports:
    - protocol: TCP
      port: 443 # HTTPS çıkışına izin ver
    

Bu NetworkPolicy'yi kubectl apply -f gelistirme-networkpolicy.yaml ile uyguladığınızda, "gelistirme" Namespace'indeki "backend" Pod'ları artık sadece tanımlanan kurallara göre iletişim kurabilecektir. NetworkPolicy'ler, çok kiracılı ortamlarda farklı güvenlik seviyelerine sahip uygulamaları veya departmanları birbirinden izole etmek için kritik bir rol oynar. Unutmamak gerekir ki, NetworkPolicy'lerin çalışabilmesi için kümenizde bir Container Network Interface (CNI) eklentisinin (örneğin Calico, Cilium, Weave Net) yüklü ve NetworkPolicy'leri desteklemesi gerekmektedir. Bu politikaların doğru yapılandırılması, bir saldırının küme içinde yayılmasını engelleyen güçlü bir savunma hattı oluşturur.

Pod Güvenlik Kabulü (Pod Security Admission - PSA) ile Güvenlik Politikaları Nasıl Uygulanır?

Kubernetes kümelerinde güvenlik, sadece kaynak izolasyonu ve ağ kontrolüyle sınırlı kalmaz; Pod'ların çalışma zamanı davranışlarını ve ayrıcalıklarını da düzenlemek gerekir. İşte burada Pod Güvenlik Kabulü (Pod Security Admission - PSA) devreye girer. PSA, Kubernetes Pod Security Standards (PSS) adı verilen önceden tanımlanmış güvenlik profillerini (Privileged, Baseline, Restricted) uygulayarak, Pod'ların güvenlik özelliklerini kontrol eden bir Admission Controller'dır. Bu standartlar, Pod'ların güvenlik seviyelerini kategorize eder ve potansiyel riskleri azaltmaya yönelik en iyi uygulamaları içerir. PSA, bir Pod'un kümede oluşturulmadan önce bu standartlara uygun olup olmadığını denetler ve uygun değilse reddedebilir.

PSA, üç temel modda çalışır:

1. Enforce (Zorunlu Kılma): Belirlenen PSS seviyesini ihlal eden Pod'ların oluşturulmasını engeller. Bu, en yüksek güvenlik seviyesini sağlar ve politikaların kesinlikle uygulanmasını ister.
2. Audit (Denetleme): Politikayı ihlal eden Pod'ların oluşturulmasına izin verir, ancak bir denetim günlüğü (audit log) kaydı oluşturur. Bu mod, mevcut iş yüklerinin uyumluluğunu değerlendirmek ve politika uygulamasına geçiş yapmak için kullanışlıdır.
3. Warn (Uyarma): Politikayı ihlal eden Pod'ların oluşturulmasına izin verir, ancak kullanıcıya bir uyarı mesajı döner. Bu mod da denetleme gibi geçiş süreçlerinde veya sadece bilgilendirme amaçlı kullanılabilir.

PSA, genellikle Namespace bazında uygulanır. Bu, her bir Namespace'in farklı güvenlik gereksinimlerine sahip olabileceği çok kiracılı ortamlarda inanılmaz bir esneklik sağlar. Örneğin, bir "gelistirme" Namespace'inde "Baseline" PSS seviyesini uygularken, daha hassas bir "uretim" Namespace'inde "Restricted" seviyesini zorunlu kılabilirsiniz. Bu, geliştiricilere daha fazla esneklik tanırken, üretim ortamının en yüksek güvenlik standartlarına uymasını sağlar.

Bir Namespace'e PSA kuralı uygulamak, Namespace'e belirli etiketler ekleyerek yapılır. Aşağıdaki örnek, "gelistirme" Namespace'ine "Baseline" Pod Security Standard'ını "enforce" modunda uygulayan etiketleri göstermektedir:

kubectl label namespace gelistirme pod-security.kubernetes.io/enforce=baseline --overwrite
kubectl label namespace gelistirme pod-security.kubernetes.io/enforce-version=latest --overwrite
    

Bu komutları uyguladıktan sonra, "gelistirme" Namespace'inde oluşturulacak tüm Pod'lar "Baseline" PSS seviyesi kurallarına göre denetlenecektir. "Baseline" standardı, bilinen ayrıcalık yükseltme açıklarını ve ciddi güvenlik risklerini engelleyen, yine de çoğu uygulama için yeterli esnekliği sağlayan bir politikadır. Örneğin, bir Pod'un hostPath birimleri kullanmasını veya ayrıcalıklı modda (privileged mode) çalışmasını engelleyebilir. Bu sayede, kötü niyetli veya yanlış yapılandırılmış Pod'ların küme güvenliğini tehlikeye atması önlenir. PSA, çok kiracılı Kubernetes ortamlarında güvenlik duruşunu güçlendirmek için güçlü ve kullanımı kolay bir mekanizmadır.

Gerçek Dünya Senaryosu: Geliştirme Ortamı İçin Çok Kiracılı Yapılandırma

Şimdiye kadar ele aldığımız tüm kavramları bir araya getirerek, gerçek bir senaryo üzerinden çok kiracılı bir Kubernetes kümesinin nasıl yapılandırılabileceğini inceleyelim. Diyelim ki, "InnovateTech" adında bir teknoloji şirketi, farklı ürün ekiplerinin (örneğin "Proje A" ve "Proje B") aynı Kubernetes kümesi üzerinde kendi uygulamalarını geliştirip test etmesini istiyor. Şirket, hem kaynakların adil dağıtımını sağlamak hem de ekipler arası güvenlik izolasyonunu garanti altına almak istiyor. İşte adım adım nasıl ilerleyebiliriz:

Adım 1: Namespace'lerin Oluşturulması

İlk olarak, her proje ekibi için ayrı Namespaces oluşturacağız. Bu, ekiplerin kaynaklarını mantıksal olarak ayıracak ve isim çakışmalarını önleyecektir.

apiVersion: v1
kind: Namespace
metadata:
  name: proje-a-dev
---
apiVersion: v1
kind: Namespace
metadata:
  name: proje-b-dev
    

Bu YAML dosyasını uyguladıktan sonra, Proje A ve Proje B'nin ayrı ayrı çalışma alanları olacaktır.

Adım 2: Kaynak Kotalarının Uygulanması

Her ekibin kümenin tüm kaynaklarını tüketmesini engellemek için Resource Quotas tanımlayacağız. Proje A için daha yoğun bir kaynak kotası belirlerken, Proje B için biraz daha kısıtlı bir kota uygulayabiliriz.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: proje-a-kota
  namespace: proje-a-dev
spec:
  hard:
    requests.cpu: "3"
    requests.memory: "6Gi"
    limits.cpu: "6"
    limits.memory: "12Gi"
    pods: "15"
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: proje-b-kota
  namespace: proje-b-dev
spec:
  hard:
    requests.cpu: "1"
    requests.memory: "2Gi"
    limits.cpu: "2"
    limits.memory: "4Gi"
    pods: "8"
    

Bu kotalar, her projenin kullanabileceği CPU, bellek ve Pod sayısını sınırlar.

Adım 3: Ağ Politikalarının Belirlenmesi (NetworkPolicies)

Proje A'nın uygulama Pod'larının sadece kendi Namespace'i içinde iletişim kurmasını ve dışarıdan gelen trafiği sadece belirli bir ingress controller'dan kabul etmesini istiyoruz. Proje B ise kendi içindeki Pod'lar arası iletişimi serbest bırakırken, dışarıya sadece HTTPS çıkışına izin verecek.

# Proje A için NetworkPolicy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: proje-a-app-isolation
  namespace: proje-a-dev
spec:
  podSelector:
    matchLabels:
      app: proje-a-app
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: ingress-nginx # veya kendi ingress Namespace'iniz
      podSelector:
        matchLabels:
          app: ingress-nginx-controller
    ports:
    - protocol: TCP
      port: 80
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
    ports:
    - protocol: TCP
      port: 443

# Proje B için NetworkPolicy (Basit İç İletişim ve HTTPS çıkışı)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: proje-b-default-deny-egress
  namespace: proje-b-dev
spec:
  podSelector: {} # Tüm Pod'lar için geçerli
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector: {} # Aynı namespace içindeki tüm Pod'lardan gelen trafiğe izin ver
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
    ports:
    - protocol: TCP
      port: 443
    

Bu politikalar sayesinde, ekiplerin uygulamaları arasında ve dış dünya ile kontrollü bir ağ iletişimi sağlanmış olur.

Adım 4: Pod Güvenlik Kabulü (PSA) Uygulanması

Son olarak, Proje A'nın Namespace'inde "Baseline" Pod Security Standard'ını zorunlu kılacağız. Proje B'ye ise denetleme modunda "Restricted" seviyesini uygulayacağız, böylece uyumsuzlukları tespit edip zamanla düzeltme imkanı sunacağız.

kubectl label namespace proje-a-dev pod-security.kubernetes.io/enforce=baseline --overwrite
kubectl label namespace proje-a-dev pod-security.kubernetes.io/enforce-version=latest --overwrite

kubectl label namespace proje-b-dev pod-security.kubernetes.io/audit=restricted --overwrite
kubectl label namespace proje-b-dev pod-security.kubernetes.io/audit-version=latest --overwrite
    

Bu etiketlemelerle, Proje A'nın Pod'ları güvenli bir yapılandırmada çalışmak zorunda kalırken, Proje B'deki olası güvenlik ihlalleri hakkında bilgi sahibi olunacaktır. Bu senaryo, Namespaces, Resource Quotas, NetworkPolicies ve PSA'nın birlikte nasıl çalışarak çok kiracılı bir Kubernetes ortamı için sağlam bir güvenlik ve izolasyon temeli oluşturduğunu göstermektedir. Bu yöntem, şirketlerin karmaşık bulut altyapılarını daha yönetilebilir, güvenli ve verimli hale getirmelerine yardımcı olur.

İleri Düzey İpuçları ve En İyi Uygulamalar

Çok kiracılı bir Kubernetes ortamı kurmak sadece temel yapılandırmalarla bitmez. Deneyimli kullanıcılar için daha da ileri giderek küme güvenliğini ve yönetilebilirliğini artıracak bazı ileri düzey ipuçları ve en iyi uygulamalar bulunmaktadır:

• Role-Based Access Control (RBAC) ile Entegre Edin: Namespaces ile birlikte RBAC'ı kullanarak, her ekibe veya kullanıcıya sadece kendi Namespaces'leri içindeki belirli kaynaklar üzerinde yetki verin. Örneğin, bir geliştiricinin yalnızca "dev" Namespace'indeki Pod'ları görüntülemesine izin verirken, "prod" Namespace'indeki hiçbir kaynağı değiştirmesini engelleyebilirsiniz. Bu, "en az ayrıcalık" ilkesini daha da güçlendirir.
• Ağ Politikalarını Kapsamlı Hale Getirin: NetworkPolicy'leri sadece Namespace izolasyonu için değil, aynı zamanda uygulama katmanı izolasyonu için de kullanın. Mikroservisler arası iletişimi kısıtlayarak, bir güvenlik açığının tüm uygulamaya yayılmasını önleyin. Varsayılan olarak tüm trafiği reddeden (default deny) NetworkPolicy'ler oluşturup, ardından sadece gerekli iletişime izin veren kuralları tanımlamak en güvenli yaklaşımdır.
• Open Policy Agent (OPA) veya Kyverno Kullanımı: PSA, Kubernetes için harika bir başlangıç noktası olsa da, daha karmaşık ve özelleştirilmiş güvenlik politikaları için Open Policy Agent (OPA) Gatekeeper veya Kyverno gibi Admission Controller'ları düşünebilirsiniz. Bu araçlar, sadece Pod güvenliği değil, tüm Kubernetes kaynakları üzerinde (Deployment, Service, Ingress vb.) ayrıntılı politika zorunluluğu sağlamanıza olanak tanır. Örneğin, belirli etiketlere sahip olmayan kaynakların oluşturulmasını engellemek veya tüm Ingress nesnelerinde HTTPS zorunluluğu getirmek gibi senaryoları yönetebilirler.
• Merkezi Loglama ve İzleme (Centralized Logging & Monitoring): Her kiracı için ayrı ayrı loglama ve izleme çözümleri kurmak yerine, tüm küme genelinde merkezi bir log toplama ve izleme sistemi (örneğin ELK Stack, Grafana/Prometheus) kullanın. Bu, olası güvenlik ihlallerini veya performans sorunlarını daha hızlı tespit etmenizi ve analiz etmenizi sağlar. Kiracılar arası log erişimini RBAC ile sınırlamayı unutmayın.
• Güvenlik Açığı Tarama ve CI/CD Entegrasyonu: Container imajlarınıza güvenlik açığı taramalarını (Vulnerability Scanning) ve CI/CD (Sürekli Entegrasyon/Sürekli Teslimat) süreçlerinize statik kod analizini entegre edin. Pod Security Admission, Pod'lar oluşturulurken bir güvenlik katmanı sunsa da, imajlardaki zafiyetleri tespit etmek için daha erken aşamalarda güvenlik kontrolleri yapmak önemlidir.
• Periyodik Denetimler ve Güvenlik Testleri: Yapılandırmalarınızın zamanla güncelliğini koruduğundan ve beklenen güvenlik seviyesini sağladığından emin olmak için düzenli güvenlik denetimleri ve sızma testleri yapın. Kubernetes yamaları (patches) ve yeni sürümlerle birlikte güvenlik davranışları değişebilir, bu nedenle sürekli adaptasyon önemlidir.
• Mobil Uyumlu Yönetim Arayüzleri: Eğer kümeniz için özel bir yönetim arayüzü veya dahili bir panel kullanıyorsanız, bu arayüzlerin mobil cihazlardan da erişilebilir ve kullanılabilir olduğundan emin olun. Özellikle acil durumlarda veya saha operasyonlarında mobil uyumluluk, yönetici deneyimini önemli ölçüde artırır. CSS media query'ler ve duyarlı tasarım ilkeleriyle bu sağlanabilir. Örneğin, geniş ekranlarda tablo şeklinde gösterilen kritik kaynak bilgilerini, küçük ekranlarda kart bazlı bir görünüme dönüştürebilirsiniz.

Bu ileri düzey uygulamalar, çok kiracılı Kubernetes ortamınızın sadece başlangıçta değil, uzun vadede de güvenli, istikrarlı ve yönetilebilir kalmasını sağlayacaktır. Güvenlik, sürekli bir süreçtir ve düzenli iyileştirmeler gerektirir.

Sonuç ve Sıkça Sorulan Sorular

Bu makalede, modern bulut altyapılarının vazgeçilmezi olan çok kiracılı Kubernetes ortamlarının güvenlik ve izolasyon temellerini ayrıntılı bir şekilde inceledik. Namespaces ile mantıksal izolasyonun nasıl sağlandığını, Resource Quotas ile kaynakların adil bir şekilde nasıl dağıtıldığını, NetworkPolicies ile ağ güvenliği sınırlarının nasıl çizildiğini ve Pod Security Admission (PSA) ile Pod'ların çalışma zamanı güvenlik politikalarının nasıl uygulandığını adım adım gördük. Tüm bu mekanizmalar, bir araya geldiğinde, farklı ekiplerin veya uygulamaların aynı Kubernetes kümesini güvenli ve verimli bir şekilde paylaşmasına olanak tanıyan sağlam bir temel oluşturur. Gerçek dünya senaryoları ve ileri düzey ipuçları ile konuyu derinlemesine ele alarak, hem yeni başlayanlara hem de deneyimli kullanıcılara pratik bilgiler sunmayı hedefledik. Kubernetes'in esnekliği sayesinde, kuruluşlar kendi özel ihtiyaçlarına göre uyarlanmış, yüksek güvenlikli çok kiracılı ortamlar kurabilirler. Ancak unutulmamalıdır ki, güvenlik statik bir durum değil, sürekli geliştirme ve denetleme gerektiren dinamik bir süreçtir.

Şimdi, konuya dair sıkça sorulan bazı sorulara göz atalım:

Sıkça Sorulan Sorular

Soru 1: NetworkPolicy'ler neden çalışmıyor olabilir?

Cevap: NetworkPolicy'lerin çalışması için Kubernetes kümenizde Calico, Cilium, Weave Net gibi NetworkPolicy'leri destekleyen bir Container Network Interface (CNI) eklentisinin kurulu ve aktif olması gerekir. Eğer yüklü değilse veya doğru yapılandırılmamışsa, politikalar uygulanmayacaktır. Ayrıca, Pod etiketlerinin ve Namespace etiketlerinin politikalarda doğru eşleştiğinden emin olun.

Soru 2: Pod Security Admission (PSA) ile Pod Security Policies (PSP) arasındaki fark nedir?

Cevap: Pod Security Policies (PSP), Kubernetes'in eski ve artık kullanımdan kaldırılmış (deprecated) bir özelliğidir. Yerine Pod Security Admission (PSA) gelmiştir. PSA, önceden tanımlanmış Pod Security Standards (PSS) profillerini (Privileged, Baseline, Restricted) kullanarak Pod güvenliğini daha basit ve standartlaştırılmış bir şekilde yönetir. PSP'ler daha esnek ama karmaşıktı ve yanlış yapılandırıldığında güvenlik açıklarına yol açabiliyordu.

Soru 3: Birden fazla kiracıya aynı kümede Persistent Volume (PV) ve Persistent Volume Claim (PVC) nasıl yönetilir?

Cevap: PVC'ler Namespace'e bağlı kaynaklardır ve Resource Quotas ile sınırlanabilirler. Her kiracının kendi Namespace'i içinde PVC'ler oluşturmasına izin vererek izolasyon sağlayabilirsiniz. Arka planda ise, farklı StorageClass'lar tanımlayarak veya depolama kotaları (Storage Quotas) belirleyerek depolama kaynaklarını yönetebilirsiniz. Örneğin, her ekibe belirli bir depolama alanı veya belirli bir performans seviyesine sahip depolama sunabilirsiniz.

Soru 4: Çok kiracılı bir ortamda güvenlik açıkları nasıl tespit edilir ve azaltılır?

Cevap: Kapsamlı bir güvenlik stratejisi uygulamak gerekir:

1. Container imajlarını düzenli olarak güvenlik açığı taramalarından geçirin.
2. Least privilege (en az ayrıcalık) ilkesini RBAC, NetworkPolicy'ler ve PSA ile uygulayın.
3. Sürekli izleme (monitoring) ve loglama (logging) ile anormallikleri tespit edin.
4. Kubernetes küme bileşenlerini güncel tutun ve güvenlik yamalarını uygulayın.
5. Periyodik güvenlik denetimleri ve sızma testleri yapın.