Kubernetes-Native Güvenlik: Pod Security Policies (PSP) Mirası ve OPA/Gatekeeper

Kubernetes (K8s) modern bulut-native uygulamaların dağıtımı, ölçeklenmesi ve yönetimi için endüstri standardı haline geldi. Ancak bu muazzam güç, karmaşık güvenlik zorluklarını da beraberinde getirdi. Konteynerler arası iletişim, ağ politikaları ve pod’ların sistem kaynaklarına erişimi gibi konular, geleneksel güvenlik paradigmalarıyla yönetilmesi zor alanlar yarattı. İşte bu noktada “Kubernetes-native güvenlik” kavramı devreye giriyor. Bu yaklaşım, güvenlik kurallarını dışarıdan bir güvenlik duvarı (firewall) veya aracı (agent) ile uygulamak yerine, doğrudan Kubernetes API sunucusu seviyesinde, ekosistemin kendi yapı taşlarını kullanarak zorunlu kılmayı amaçlar.

Bu makalede, Kubernetes-native güvenliğin evrimini, artık kullanımdan kaldırılmış (deprecated) olan Pod Security Policies (PSP) ile modern ve esnek bir alternatif olan OPA (Open Policy Agent) / Gatekeeper karşılaştırması üzerinden derinlemesine inceleyeceğiz. Ayrıca Kyverno ve Falco gibi diğer önemli açık kaynak çözümlere de değinerek küme (cluster) güvenliğinizi nasıl bir üst seviyeye taşıyabileceğinizi keşfedeceğiz.

Güvenliğin Kapı Bekçileri: Admission Controllers (Kabul Denetleyicileri)

Kubernetes-native güvenlik çözümlerinin nasıl çalıştığını anlamak için öncelikle Admission Controllers (Kabul Denetleyicileri) kavramını bilmemiz gerekir. Kubernetes API sunucusuna gelen her istek (örneğin, yeni bir Pod oluşturma, bir Service’i güncelleme) bir dizi aşamadan geçer. Admission Controller’lar, bu isteğin API sunucusu tarafından işlenip veritabanına (etcd) kaydedilmesinden hemen önce devreye giren eklentilerdir.

İki tür Admission Controller vardır:

1. Mutating Admission Webhooks: İsteği değiştirebilirler. Örneğin, bir Pod tanımına her zaman belirli bir label (etiket) ekleyebilir veya eksik olan kaynak limitlerini (resource limits) otomatik olarak doldurabilirler.
2. Validating Admission Webhooks: İsteği doğrularlar. İsteğin içeriğini (örneğin, Pod’un güvenlik ayarlarını) önceden tanımlanmış politikalara göre kontrol ederler. Politika ihlal edilirse, isteği reddederler ve kullanıcıya bir hata mesajı döndürürler.

Hem PSP hem de OPA/Gatekeeper, temelde bu Admission Controller mekanizmasını kullanarak politikaları zorunlu kılar.

Eski Standart: Pod Security Policies (PSP) Nedir?

Pod Security Policies (PSP), uzun süre Kubernetes’in yerleşik bir güvenlik özelliği olarak hizmet verdi. Temel amacı, bir Pod’un oluşturulurken veya güncellenirken sahip olabileceği güvenlik bağlamını (security context) kontrol etmekti.

PSP’ler, küme düzeyinde (cluster-level) tanımlanan kaynaklardı ve yöneticilerin şu gibi kritik ayarları kısıtlamasına olanak tanırdı:

• Privileged Konteynerler: privileged: true ayarını engelleyerek konteynerlerin ana makine (node) üzerinde tam root erişimine sahip olmasını önler.
• Host Network/PID/IPC Kullanımı: Pod’ların ana makinenin ağ, process ID veya IPC namespace’lerini paylaşmasını engeller.
• Volume Türleri: Hangi tür volume’lerin (örneğin hostPath) kullanılabileceğini kısıtlar.
• Kullanıcı ve Grup ID’leri: Konteynerlerin hangi runAsUser veya runAsGroup ID’leri ile çalışabileceğini zorunlu kılar.
• ReadOnly Root Filesystem: Konteynerin dosya sisteminin salt okunur olmasını zorunlu kılar.

PSP’nin Çalışma Mantığı ve Zorlukları

PSP’nin çalışma şekli, gücünün yanı sıra en büyük zayıflığıydı. Bir PSP tanımlamak yeterli değildi; bu politikayı kullanma yetkisinin, Pod’u oluşturan ServiceAccount‘a RBAC (Role-Based Access Control) kuralları (Roller ve RoleBinding’ler) aracılığıyla verilmesi gerekiyordu.

Bu durum, özellikle çok kullanıcılı veya çok namespace’li kümelerde yönetimi son derece karmaşık hale getiriyordu:

1. Kullanılabilirlik Sorunları: Yöneticiler genellikle çok kısıtlayıcı bir PSP oluşturur ve bunu tüm ServiceAccount’lara atamayı unuturdu. Sonuç? Geliştiriciler en basit Pod’ları bile oluşturamaz hale gelir ve “Permission Denied” hatalarıyla karşılaşırdı.
2. Esneklik Eksikliği: PSP’ler, “bu Pod bu politikayı kullanabilir” şeklinde çalışırdı. Hangi politikanın otomatik olarak uygulanacağını belirlemek zordu. Genellikle birden fazla PSP eşleşir ve Kubernetes hangisini seçeceğine karar vermekte zorlanırdı.
3. Test Edilebilirlik: Bir PSP politikasını “dry-run” (deneme modu) ile test etme veya “audit” (denetim) modunda çalıştırma yeteneği yoktu. Bir politika uygulandığı anda kuralı ihlal eden her şeyi engellemeye başlardı.

Bu nedenlerden dolayı Kubernetes topluluğu, Kubernetes 1.21 sürümünde PSP’yi “deprecated” (kullanımdan kaldırılıyor) olarak işaretledi ve 1.25 sürümünde tamamen kaldırdı. Artık PSP kullanmak, sürdürülebilir bir güvenlik stratejisi değildir.

Yeni Nesil Politika Yönetimi: OPA (Open Policy Agent) ve Gatekeeper

PSP’nin bıraktığı boşluğu doldurmak için CNCF (Cloud Native Computing Foundation) bünyesinde geliştirilen Open Policy Agent (OPA), hızla endüstri standardı haline geldi.

OPA (Open Policy Agent) Nedir?

OPA, yalnızca Kubernetes için değil, genel amaçlı bir politika motorudur. Mikroservisler, CI/CD pipeline’ları, API ağ geçitleri ve Kubernetes dahil olmak üzere teknoloji yığınınızın herhangi bir katmanında politikaları yönetmek için tasarlanmıştır.

OPA’nın temel gücü, Rego adı verilen özel bir sorgu dilinden gelir. Rego, JSON veya YAML formatındaki verileri (örneğin, Kubernetes Pod tanımını) alıp, bu verinin politikalara uyup uymadığını sorgulamanıza olanak tanır.

Gatekeeper Nedir? OPA’nın Kubernetes ile Bütünleşmesi

OPA genel amaçlı bir araçken, Gatekeeper, OPA’yı özel olarak Kubernetes üzerinde “native” bir şekilde çalıştırmak için tasarlanmış bir projedir. Gatekeeper, OPA motorunu alır ve onu doğrudan Kubernetes Admission Controller mekanizmasına bağlar.

Gatekeeper, kümeye kurulduğunda iki temel bileşen sunar:

1. Validating Admission Webhook: API sunucusuna gelen tüm istekleri (CREATE, UPDATE, DELETE) yakalar ve OPA motoruna “Bu isteğe izin verilmeli mi?” diye sorar.
2. CRD’ler (Custom Resource Definitions): Politikaların Kubernetes’in kendi nesneleri (YAML dosyaları) olarak tanımlanmasını sağlar.

Bu mimari, “Policy-as-Code” (Kod Olarak Politika) yaklaşımını mükemmel bir şekilde destekler. Güvenlik politikalarınız, tıpkı Deployment veya Service YAML’leriniz gibi Git repositorilerinde saklanabilir, versiyonlanabilir ve GitOps araçlarıyla (ArgoCD, Flux vb.) otomatik olarak kümelere dağıtılabilir.

Gatekeeper Mimarisi: ConstraintTemplates ve Constraints

Gatekeeper’ın kullanımı PSP’ye göre çok daha esnek ve anlaşılırdır. İki ana kaynağa dayanır:

1. ConstraintTemplate (Kısıtlama Şablonu):
   • Bu, politikanın mantığını tanımlar.
   • “Bir Pod hangi koşulları sağlamalıdır?” sorusunun cevabıdır.
   • İçerisinde Rego kodu bulunur.
   • Örnek Şablon: “Tüm konteyner imajları (images) yalnızca ‘gcr.io’ veya ‘https://www.google.com/search?q=private.registry.com’ adresinden gelmelidir.”
2. Constraint (Kısıtlama):
   • Bu, ConstraintTemplate‘i alıp nerede ve nasıl uygulanacağını belirler.
   • Örnek Kısıtlama: “Yukarıdaki ‘Güvenilir Registry’ şablonunu al ve bunu sadece prod ve staging namespace’lerindeki Pod’lara uygula.”

Bu ayrım sayesinde, bir güvenlik ekibi karmaşık Rego kodunu içeren ConstraintTemplate‘leri bir kez yazar ve geliştirici ekipler bu şablonları kendi namespace’lerinde basit Constraint YAML’leri ile kolayca kullanabilir.

PSP vs. OPA/Gatekeeper: Neden Gatekeeper Kazanıyor?

Pratik Örnekler: Gatekeeper ile Yaygın Güvenlik Politikaları

Gatekeeper’ın gücünü görmek için PSP’nin yaptığı (ve yapamadığı) bazı yaygın senaryoları nasıl ele aldığına bakalım.

Örnek 1: Privileged Konteynerleri Engelleme (PSP Yerine Geçme)

PSP’nin ana görevlerinden biri buydu. Gatekeeper ile bu kuralı tanımlamak çok basittir.

1. Adım: ConstraintTemplate (Mantık) Bu şablon, securityContext.privileged alanının true olarak ayarlanıp ayarlanmadığını kontrol eder.

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8sdisallowprivileged
spec:
  crd:
    spec:
      names:
        kind: K8sDisallowPrivileged
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8sdisallowprivileged
        
        violation[{"msg": msg}] {
          input.review.object.spec.template.spec.containers[_].securityContext.privileged == true
          msg := "Privileged containers are not allowed."
        }
        
        # Bu kısım Deployment/StatefulSet gibi üst nesneler yerine doğrudan Pod için
        violation[{"msg": msg}] {
          input.review.object.kind == "Pod"
          input.review.object.spec.containers[_].securityContext.privileged == true
          msg := "Privileged containers are not allowed."
        }

2. Adım: Constraint (Uygulama) Şimdi bu kuralı tüm kümede (veya belirli namespace’lerde) uygulayalım.

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sDisallowPrivileged
metadata:
  name: block-privileged-containers
spec:
  match:
    kinds:
      - apiGroups: ["", "apps", "batch"]
        kinds: ["Pod", "Deployment", "StatefulSet", "Job", "DaemonSet"]

Artık privileged: true içeren herhangi bir Pod veya Deployment API sunucusu tarafından reddedilecektir.

Örnek 2: Güvenilir Kaynaklardan Image Kullanımını Zorunlu Kılma

Bu, PSP’nin yapamadığı bir şeydi. Gatekeeper ile çok kolaydır.

1. Adım: ConstraintTemplate (Mantık) (Rego kodu, imaj adının belirli bir prefix ile başlayıp başlamadığını kontrol eder)

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequireimageregistry
spec:
  crd:
    spec:
      names:
        kind: K8sRequireImageRegistry
      parameters:
        - name: registries
          type: "array"
          description: "İzin verilen registry listesi (örn: 'my-registry.com/')"
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequireimageregistry

        violation[{"msg": msg}] {
          container := input.review.object.spec.template.spec.containers[_]
          allowed_registries := input.parameters.registries
          
          # İmajın izin verilen registry'lerden biriyle başlamadığını kontrol et
          not any_match(allowed_registries, container.image)
          
          msg := sprintf("Image '%v' comes from an untrusted registry. Allowed registries: %v", [container.image, allowed_registries])
        }
        
        any_match(list, str) {
          startswith(str, list[_])
        }

2. Adım: Constraint (Uygulama) Şimdi prod namespace’i için sadece belirli registry’lere izin verelim.

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequireImageRegistry
metadata:
  name: require-prod-registry
spec:
  match:
    kinds:
      - apiGroups: ["apps"]
        kinds: ["Deployment", "StatefulSet"]
    namespaces:
      - "prod"
  parameters:
    registries:
      - "gcr.io/my-prod-project/"
      - "docker.io/my-organization/"

Artık prod namespace’inde docker.io/nginx gibi genel bir imaj kullanılarak Deployment oluşturulamaz.

Diğer Açık Kaynak Kubernetes-Native Güvenlik Çözümleri

Güvenlik, Gatekeeper ile bitmiyor. Ekosistemde, farklı sorunlara odaklanan başka güçlü açık kaynak araçlar da bulunmaktadır.

1. Kyverno: OPA’ya Kubernetes-Odaklı Alternatif

Kyverno, OPA/Gatekeeper’a doğrudan bir rakiptir ve popülaritesi hızla artmaktadır. OPA’nın aksine, Kyverno sadece Kubernetes için tasarlanmıştır.

En büyük avantajı, politika dilidir. Kyverno, politikaları tanımlamak için Rego dilini kullanmaz. Bunun yerine, politikalar doğrudan Kubernetes YAML formatında, bildirimsel (declarative) bir sözdizimi ile yazılır. Bu, Rego öğrenmek istemeyen veya Kubernetes yöneticileri için öğrenme eğrisini ciddi şekilde düşürür.

Kyverno üç temel işlevi yerine getirir:

• Validate (Doğrulama): Gatekeeper gibi, kaynakların kurallara uymasını zorunlu kılar (örn: “Her Pod’un ‘owner’ etiketi olmalı”).
• Mutate (Değiştirme): Kaynakları oluşturulurken otomatik olarak değiştirir (örn: “Eğer bir Pod’da ‘resource limits’ yoksa, varsayılan 100m CPU ekle”).
• Generate (Oluşturma): Bir kaynak oluşturulduğunda başka kaynakları tetikleyip oluşturabilir (örn: “Yeni bir Namespace oluşturulduğunda, otomatik olarak varsayılan bir ‘NetworkPolicy’ de oluştur”).

Eğer Rego’nun karmaşıklığı sizi OPA’dan uzaklaştırıyorsa, Kyverno mükemmel bir açık kaynak alternatiftir.

2. Falco: Çalışma Zamanı (Runtime) Güvenliği

Şimdiye kadar bahsettiğimiz tüm araçlar (PSP, Gatekeeper, Kyverno) Admission Control (Kabul Denetimi) üzerine odaklıydı. Yani, bir Pod’un çalışmaya başlamadan önce kurallara uymasını sağlarlardı.

Peki, Pod çalışmaya başladıktan sonra ne olur?

İşte burada Falco (bir diğer CNCF projesi) devreye girer. Falco, bir “Runtime Güvenlik” aracıdır.

Falco, Pod’un içinde çalışmaz. Ana makine (node) seviyesinde, eBPF veya kernel modülleri aracılığıyla Linux sistem çağrılarını (syscalls) dinler. Bu sayede, çalışan konteynerlerin davranışlarını izler.

Falco’nun tespit edebileceği anormal durumlara örnekler:

• “Bir konteyner, /etc/shadow (şifre dosyası) dosyasına okuma/yazma girişiminde bulundu.”
• “Bir nginx konteyneri, beklenmedik bir şekilde dışarıya giden bir SSH bağlantısı başlattı.”
• “Bir Pod’un içinde bir shell (bash, sh) başlatıldı.”
• “Konteyner, /var/log dizini dışında bir yere log yazmaya çalıştı.”

Özetle: Gatekeeper/Kyverno kümeye neyin girebileceğine karar verirken, Falco kümeye giren şeylerin içeride ne yaptığına bakar. Kapsamlı bir güvenlik stratejisi için her ikisine de ihtiyaç vardır.

Ticari ve Kısmi Ticari Çözümler

Açık kaynak araçlar son derece güçlü olsa da, büyük kurumsal ortamlarda genellikle ek özelliklere ihtiyaç duyulur. Ticari çözümler, genellikle yukarıda bahsedilen açık kaynak projeleri (OPA, Falco gibi) temel alır ve bunların üzerine ek özellikler koyar.

Bu çözümler genellikle şunları sunar:

• Birleşik Gösterge Paneli (Dashboard): Tüm kümelerdeki politika ihlallerini, runtime uyarılarını ve zafiyet taramalarını tek bir merkezi arayüzden yönetme.
• Vulnerability Scanning (Zafiyet Tarama): Konteyner imajlarını ve çalışan Pod’ları bilinen CVE (Common Vulnerabilities and Exposures) açıklarına karşı tarama.
• CIS Benchmark ve Uyumluluk Raporlaması: PCI-DSS, HIPAA, GDPR gibi standartlara uyumluluğu otomatik olarak denetleme ve raporlama.
• Kurumsal Destek: 7/24 teknik destek.

Bu alandaki bazı popüler ticari platformlar arasında Palo Alto Networks (Prisma Cloud), Aqua Security, Sysdig ve Red Hat Advanced Cluster Security (ACS) bulunmaktadır.

Politika Odaklı Kubernetes Güvenliğine Geçiş

Kubernetes güvenlik manzarası, Pod Security Policies (PSP) gibi yerleşik ancak katı ve kullanışsız araçlardan, Policy-as-Code (Kod Olarak Politika) felsefesini benimseyen esnek ve güçlü motorlara doğru evrildi.

OPA/Gatekeeper, Rego’nun sunduğu sonsuz esneklik sayesinde, sadece Pod güvenliğini değil, tüm Kubernetes kaynaklarının yapılandırmasını yönetmek için fiili standart haline gelmiştir. Kyverno ise, Kubernetes’e özgü daha basit bir sözdizimi arayanlar için güçlü bir alternatif sunar.

Unutulmamalıdır ki, güvenliğinizi sadece Admission Control (kabul denetimi) ile sınırlamak yeterli değildir. Falco gibi runtime güvenlik araçlarıyla bu politikaları tamamlamak, hem kümenize girenleri hem de içeride yaptıklarını kontrol ederek “derinlemesine savunma” (defense-in-depth) stratejisi oluşturmanın anahtarıdır.

Kubernetes yolculuğunuzda güvenliği bir sonradan eklenecek bir adım olarak değil, OPA ve Gatekeeper gibi “native” araçlarla sistemin ayrılmaz bir parçası olarak ele almak, sürdürülebilir ve ölçeklenebilir bir başarının temel taşıdır…

Lütfen Dikkat! Sitemizi kaynak göstermeden kesinlikle alıntı yapmayınız!!!