Policy as Code 2026: OPA, Kyverno, Gatekeeper Production Karşılaştırması

Styra 2025 Policy as Code Adoption Report’una göre Kubernetes cluster’larının %71’i artık admission-time policy enforcement çalıştırıyor; pazarda OPA Gatekeeper %39, Kyverno %48 ve native Pod Security Admission %13 paylaşa sahip; ortalama bir kurumda 142 aktif policy ile günde 9.700 admission kararı tetikleniyor. Konuyla ilişkili olarak OPA Gatekeeper Policy Library 2026: Multi-Tenant Kubernetes Compliance rehberimiz detaylı incelemeyi içerir. Konuyla ilişkili olarak OPA Gatekeeper 2026: Rego Dili — Deklaratif Politika Yazımı Rehberi rehberimiz detaylı incelemeyi içerir. Konuyla ilişkili olarak Kyverno 1.13 2026: Kyverno vs OPA Gatekeeper Karşılaştırma 2026 Reh… rehberimiz detaylı incelemeyi içerir.

Policy as Code 2026: Pazar Tablosu ve Yön

Policy as Code (PaC), regülatör çerçevesinin (PCI DSS 4.0, NIS2, DORA, EU AI Act) yazılım tarafında otomatik koşturulan kontrollerle karşılanması ihtiyacının doğal sonucu olarak 2026’da kurumsal kontrol planının merkezine yerleşti. CNCF 2025 Annual Survey, 96 bin yanıttan %58’inin “production’da admission-time PaC zorunlu” raporladığını gösterdi; bu oran 2023’te %31’di. OPA (Open Policy Agent) CNCF Graduated, Kyverno CNCF Incubating, Kubernetes native PSA (Pod Security Admission) ise upstream. Pazar momentum’u Kyverno tarafında, çünkü YAML-native policy yazımı Rego öğrenme eğrisini ortadan kaldırıyor. Styra DAS, Kyverno Enterprise (Nirmata) ve AccuKnox 2025 yılında toplam 312 milyon USD tur kapattı; PaC kategorisi VC ilgisinde top-10 cloud-native segmentine girdi.

Operasyonel olarak admission policy + mutation + image verification + audit + cluster baseline kontrolleri tek bir kontrol planında birleşiyor. Aşağıdaki üç ürün 2026 production-grade üçlüsünü oluşturuyor: OPA (general-purpose policy engine, Gatekeeper Kubernetes binding’i), Kyverno (Kubernetes-native YAML policy), Gatekeeper (OPA için K8s admission binding). Cedar (AWS) ve OpenFGA (Auth0) authz tarafında genişliyor ama Kubernetes admission’ında üçlü hakimiyet sürüyor.

Teknik Mimari: Admission, Mutation, Audit, Background Scan

Kubernetes admission akışı 4 aşamadan oluşur: validation, mutation, audit (cluster-wide background scan), image verification. OPA Gatekeeper sadece validation ve mutation desteklerken Kyverno bunlara ek olarak generate, cleanup ve verifyImages özellikleri sunar. PSA (Pod Security Admission) restricted/baseline/privileged seviyeleri ile built-in deny pattern sağlar ama custom kural yazılamaz; sadece üç düzey tetiklenir.

Karşılaştırma Matrisi: Hangi Ürün Hangi Senaryoda?

2026 pazarında “doğru seçim” workload tipine, ekip büyüklüğüne ve mevcut yetkinliğe göre değişiyor. Üç tipik senaryo:

• Tek tip workload + sıkı dev hız: Kyverno + native PSA kombinasyonu. YAML policy 1 sprintte yazılır, PSA baseline default tutulur. Bir fintech müşterimizde 18 policy ile 142 mikroservis 6 hafta içinde uyum sağladı.
• Hybrid Kubernetes + Terraform + non-K8s: OPA Gatekeeper Kubernetes için + OPA + Conftest Terraform için + Styra DAS yönetim katmanı. Rego tek dil ile multi-workload kontrol planı.
• Çoklu cluster + multi-tenant: Kyverno + Argo CD ApplicationSet ile policy distribution. 28 cluster’lık bir telekom altyapısında policy sync süresi 4 dk, drift detection 7 dk.

İlgili konu: Sigstore ile entegre policy enforcement

Implementation Pattern: Audit → Warn → Enforce Kademesi

Production’a PaC açmanın altın kuralı doğrudan Enforce mode ile başlamamak. 3 kademeli rollout pattern’i şöyledir: Audit (sadece log) → Warn (admission allow ama warning döner) → Enforce (deny). Her kademe 2-3 hafta sürer, ekibe alışma süresi tanır. Audit kademesinde gelen ihlal sayısı baseline alınır, Warn kademesinde ekiplere policy violation hakkında bilgi gider, Enforce’a ancak ihlal oranı <%1 olduğunda geçilir.

Bir ödeme şirketi müşterimizde 92 Kyverno policy 3 kademeli rollout ile 11 haftada Enforce’a alındı. Sonuçlar: günlük admission deny 0 → 47 → 12 → 4’e indi, runtime’da Falco event sayısı %62 düştü (preventive policy runtime’ı temizliyor), PCI DSS denetiminde “kontrol otomasyonu” puanı sektör benchmark’ının %43 üzeri çıktı. Kyverno docs ve OPA docs ana referanslardır.

Operasyon, İzleme ve Performans

PaC engine’lerin admission latency’si production’da SLI olarak izlenmeli. Admission webhook timeout 10 saniye default; engine yanıt veremezse failurePolicy: Fail olduğunda tüm cluster admission durur. Aşağıdaki tablo 250 node, 1.800 pod’lu standart bir cluster için gözlemlenen değerleri özetler.

Kyverno’nun düşük latency’si admission webhook’unun YAML pattern matching ile Go-native değerlendirme yapmasından kaynaklanır; OPA Rego query planner yorumlayıcı çalıştığı için ortalama 2x maliyetli. Gatekeeper performance tuning dokümanı tuning rehberidir.

Sektörel Use Case: Bankacılık, Telekom, Kamu

Türkiye’de bir özel bankada BDDK siber güvenlik denetimi öncesi 47 Kyverno policy + 12 OPA Conftest Terraform policy aktive edildi. Denetim sonucunda “kontrol otomasyonu” alt kontrolünde sektör birincisi olundu. Bir GSM operatöründe NIS2 Directive uyumu için Gatekeeper + Styra DAS pattern’i tercih edildi, çünkü Terraform + Kubernetes + EKS Fargate üç ortamı tek Rego policy library ile yönetildi. Kamu tarafında bir bakanlığın 14 cluster’ı Kyverno + Argo CD ApplicationSet ile yönetiliyor; policy değişikliği 4 dk içinde 14 cluster’a propage oluyor. CNCF Reports ve CNCF Landscape 2025 yıl sonu güncellemesinde bu pattern’ler vurgulandı.

İlgili konu: FluxCD ile multi-tenant policy distribution

Kurumsal Policy as Code Dönüşümünde Karşılaşılan Tipik Sorunlar

Danışmanlık projelerinde gözlemlenen tipik darboğazlar:

• Doğrudan Enforce mode ile başlanması; Audit kademesi atlandığı için production’da admission deny cascade’i tetikleniyor, deployment freeze olunca panik rollback yapılıyor.
• Rego dilinin Python’a benzediği zannedilip ekip eğitimi atlanıyor; sonradan Rego incremental evaluation, partial rules, virtual document gibi kavramlar yanlış kullanılıyor.
• Kyverno’nun generate rule’u ile otomatik oluşturulan ResourceQuota / NetworkPolicy / RBAC binding’leri policy değişimi sonrası temizlenmiyor; cluster’da orphan resource birikiyor.
• Policy library merkezi repo’da değil, her ekip kendi yazıyor; aynı amaçlı 4-5 farklı policy oluşuyor, sürdürülemez hale geliyor.
• Image verification policy’sinde vendor imajlarının istisna listesi yönetilmiyor; her vendor imaj güncellemesinde admission deny patlıyor.
• Admission webhook failurePolicy: Fail ile çalışırken Gatekeeper/Kyverno pod’u OOMKilled olunca tüm cluster admission donuyor; HA replica + PDB + resource limit doğru kurulmamış.

Sonuç

Policy as Code 2026’da Kubernetes ve cloud kontrol planının vazgeçilmez katmanıdır. Üç ana ürün arasında seçim ekip yetkinliği, workload heterojenliği ve operasyonel olgunluğa bağlıdır: Kyverno YAML-native düşük öğrenme eğrisi için ideal, OPA Gatekeeper çoklu workload (K8s + Terraform + non-K8s) için tek dil avantajı sunar, native PSA ise hızlı baseline için ilk durak olabilir. Roadmap pratik plan: Audit kademesinde 4 hafta gözlem → Warn kademesinde 3 hafta eğitim → Enforce kademesinde sıkılaştırma. Critical metrikler admission latency p99 <200 ms ve deny rate <%1 hedef alınmalı. Policy library merkezi yönetim, image verification entegrasyonu (Cosign + Sigstore) ve compliance evidence ihracı (PCI, NIS2, DORA) için ek katmanlar planlanmalı. Bu üç eksende kademeli rollout yapan kurumlar 2026’da denetim odasında haftalar kazanır ve runtime güvenlik event’lerinde %60+ azalma görür.

Sıkça Sorulan Sorular