Kubernetes PSA + Kyverno ile Aşamalı Sertleştirme

Kubernetes güvenliğinde en yaygın iki uç hata:

1. “Şimdilik serbest bırakalım, sonra bakarız” → yıllarca biriken risk
2. “Her şeyi enforce edelim” → bir sabah deploy’ların yarısı patlar, geri alınır

Sahada en sürdürülebilir yol kademeli sertleştirme: önce görünürlük, sonra uyarı, en son zorunlu kılma. PSA (Pod Security Admission) bunun için iyi bir temel sağlar; Kyverno ise PSA’nın kapsamadığı pratik güvenlik ihtiyaçlarını policy’ye döker.

1) PSA’yı doğru konumlandır: “baseline” bir başlangıçtır

PSA üç seviye etrafında düşünülür:

• privileged (en gevşek)
• baseline (makul minimum)
• restricted (daha sıkı)

PSA’nın gücü: namespace bazında, standart bir çerçeveyle çalışır. Zayıf yanı: kuruma özel ihtiyaçlar (registry allowlist, label zorunluluğu vb.) PSA ile çözülmez.

2) Strateji: audit → warn → enforce

Ben production’da şu sırayı öneriyorum:

1. Audit: sadece logla (etki yok)
2. Warn: kullanıcıyı uyar (hala çalışır)
3. Enforce: reddet (artık guardrail)

Bu sıranın amacı “yumuşak olmak” değil; sinyal toplamak ve patlamayı önlemektir.

3) Namespace etiketleri ile PSA devreye alma

Örnek: önce tüm namespace’lerde baseline’ı audit/warn ile açın:

apiVersion: v1
kind: Namespace
metadata:
  name: app-prod
  labels:
    pod-security.kubernetes.io/audit: baseline
    pod-security.kubernetes.io/warn: baseline

Sonra raporlar oturduğunda enforce’a geçin:

metadata:
  labels:
    pod-security.kubernetes.io/enforce: baseline

4) PSA’nın yakalayamadığı yer: kurumsal guardrail ihtiyacı

PSA seviyeleri, tüm kurumların ihtiyaçlarını kapsamaz. Örneğin:

• Sadece belirli registry’lerden image çekilsin
• Privileged container sadece belirli namespace’lerde olsun
• hostPath istisnaları kontrollü olsun
• runAsNonRoot, readOnlyRootFilesystem gibi pratikler zorunlu olsun

Bu noktada Kyverno gibi policy engine’ler devreye girer.

5) Kyverno ile “en yüksek değer” policy’ler

A) Privileged ve hostPath kısıtları

Örnek yaklaşım: default’ta yasakla, sadece “infra” namespace’ine izin ver.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-privileged-except-infra
spec:
  validationFailureAction: Audit
  rules:
    - name: privileged-only-in-infra
      match:
        any:
          - resources:
              kinds: ["Pod"]
      validate:
        message: "Privileged yalnızca infra namespace'inde izinli."
        deny:
          conditions:
            any:
              - key: "{{ request.object.metadata.namespace }}"
                operator: NotEquals
                value: "infra"
              - key: "{{ request.object.spec.containers[].securityContext.privileged || `false` }}"
                operator: Equals
                value: true

Not: Kyverno örneklerini kendi sürümünüz ve CRD yapınıza göre uyarlayın. Ama prensip aynı: önce Audit ile sinyal topla.

B) Registry allowlist (supply chain kontrolü)

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: image-registry-allowlist
spec:
  validationFailureAction: Audit
  rules:
    - name: only-approved-registries
      match:
        any:
          - resources:
              kinds: ["Pod"]
      validate:
        message: "Image sadece onaylı registry'lerden çekilebilir."
        pattern:
          spec:
            containers:
              - image: "registry.example.com/* | ghcr.io/org/*"

C) readOnlyRootFilesystem + runAsNonRoot (kademeli sıkılaştırma)

Önce warn/audit ile başlayıp, sonra enforce:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-nonroot-and-readonly
spec:
  validationFailureAction: Audit
  rules:
    - name: nonroot-readonly
      match:
        any:
          - resources:
              kinds: ["Pod"]
      validate:
        message: "Container'lar non-root ve read-only rootfs olmalı."
        pattern:
          spec:
            containers:
              - securityContext:
                  runAsNonRoot: true
                  readOnlyRootFilesystem: true

6) İstisna yönetimi: “policy bypass” değil, “policy contract”

İstisnalar kaçınılmazdır (node-exporter, CNI, storage driver vb.). Burada kritik olan:

• İstisna “kime, neden, ne kadar süre” sorularına cevap versin
• Süreli olsun (örn. 30 gün)
• Owner’ı ve risk notu belli olsun

Pratik çözüm:

• exceptions/ klasöründe YAML istisna dosyaları
• PR ile onay
• Etiket/annotation ile expiry ve owner

7) Runbook: “Pod rejected” incident’ı

1. Hata PSA mı Kyverno mu? (event ve admission mesajı)
2. Namespace policy seviyesi nedir? (label kontrolü)
3. Hangi alan takıldı? (privileged, hostPath, capabilities vb.)
4. Çözüm:
   • Workload’u düzelt (tercih)
   • Geçici istisna (süreli + owner)
   • Yanlış policy (kuralı düzelt, sonra tekrar Audit’e dön)

Kapanış

PSA + Kyverno; Kubernetes güvenliğini “her deploy’da pazarlık” olmaktan çıkarıp, ürünleşmiş bir guardrail setine dönüştürür. Başarının anahtarı teknoloji değil; aşamalı geçiş, istisna disiplini ve ölçümdür.