OPA Gatekeeper 3.16 sürümü 2026 Q1’de yayınlandı ve Sysdig 2025 Kubernetes Security Report’a göre kurumsal multi-tenant cluster’ların yüzde 64’ü Gatekeeper veya Kyverno gibi policy as code çözümlerini production’da kullanıyor. Policy library tasarımı kurumsal compliance projelerinin başarı veya başarısızlık çizgisini belirliyor.
OPA Gatekeeper Policy Library 2026 Pazarı
Open Policy Agent (OPA) projesi CNCF Graduated proje olarak 2026’da 18 bin GitHub yıldızını geçti ve haftalık 12 milyon Docker pull oranına ulaştı. Gatekeeper ise Kubernetes admission controller olarak OPA’yı entegre ederek ConstraintTemplate ve Constraint CRD’leri üzerinden policy yönetimi sağlıyor. CNCF Annual Survey 2025’e göre Kubernetes kullanıcılarının yüzde 47’si Gatekeeper, yüzde 31’i Kyverno, yüzde 14’ü Polaris kullanıyor.
Multi-tenant cluster’larda policy library tasarımı kritik. Kurumsal kuruluşlar ortalama 47-120 farklı constraint çalıştırıyor (Datadog 2025 State of Cloud Security raporu). Bu constraint’lerin yüzde 73’ü standart OPA Gatekeeper Library’sinden adapte ediliyor; yüzde 27’si kurum-spesifik. Constraint library yönetimi için GitOps pattern (Flux veya ArgoCD ile) artık endüstri standardı; manuel kubectl apply approach yüzde 67 oranında policy drift’e yol açıyor.
Constraint Template Mimari Boyutu
ConstraintTemplate Rego dili ile yazılan policy logic’i ve violation message şablonlarını içerir. Constraint ise template’ten türetilen ve match selector (namespaces, labels, kinds) ile hangi resource’lara uygulanacağını belirten instance. Gatekeeper 3.16 ile mutation, external data provider ve referential constraint (cross-resource policy) tam destek aldı. Audit mode ve enforcement mode (deny, warn, dryrun) granular kontrol sunuyor.
| Özellik | OPA Gatekeeper 3.16 | Kyverno 1.13 | Polaris 9 |
|---|---|---|---|
| Dil | Rego | YAML | YAML |
| Mutation | Evet (alpha) | Evet (stable) | Hayır |
| External Data | Evet (provider) | Evet (image registry) | Hayır |
| Referential Constraint | Evet | Evet | Hayır |
| Library Sayısı | 120+ standart | 240+ standart | 15+ standart |
| Webhook Latency | 15-45 ms | 20-60 ms | 10-25 ms |
Multi-Tenant Compliance Pattern ve Karşılaştırma
Multi-tenant cluster’larda en yaygın 8 constraint kategorisi: resource limits, image registry whitelist, security context, ingress/egress network, RBAC binding, pod security standards, label/annotation policy, ve image vulnerability gate. Her tenant için ayrı Constraint instance oluşturmak yerine ExcludedNamespaces ve namespaceSelector ile tek constraint çoklu tenant’a uygulanabilir.
- Resource Limits: CPU/memory request ve limit zorunluluğu, quota %85 doluluk uyarısı.
- Image Registry: ECR, GCR, Harbor whitelist; public Docker Hub default ret.
- Security Context: runAsNonRoot, readOnlyRootFilesystem, allowPrivilegeEscalation false.
- Network Policy: Default-deny ingress/egress, egress için DNS exception zorunlu.
- RBAC: cluster-admin binding yasak, namespace admin için sadece tenant SA.
- Pod Security: restricted profile zorunlu, baseline sadece kube-system için.
İlgili konu: Kubernetes multi-tenant mimari pattern namespace isolation ile constraint kombinasyonunu detaylandırıyor.
Implementation Pattern ve Production Best Practices
Production deployment için Gatekeeper webhook 3 replica HA ile çalıştırılmalı; webhook failure tolerance failurePolicy=Ignore başlangıçta ama hardening sonrası Fail’e geçirilir. Audit interval default 60 saniye yeterli ama 5000+ namespace’li cluster’larda 300 saniyeye çıkarılmalı (etcd yükü için). Validation timeout 3 saniye default; karmaşık Rego policy’lerde 5 saniyeye çıkarılmalı ama bu API server latency’sini etkiler.
Constraint library GitOps pattern ile yönetilir. Flux v2 veya ArgoCD ApplicationSet ile constraint template’ler önce deploy edilir, 60 saniye stabilizasyon sonrası constraint instance’lar uygulanır; bu sıralama race condition’ı önler. Yeni constraint her zaman önce enforcementAction=dryrun ile 7 gün izlenir, sonra deny modunda etkinleştirilir. Violation count Prometheus metric olarak gatekeeper_violations’tan toplanır.
Operasyon, İzleme ve Maliyet Modellemesi
Gatekeeper webhook kaynak tüketimi cluster boyutuna göre değişir. 1000 pod’luk cluster’da webhook 0,4 vCPU ve 512 MB memory ortalama; ConstraintTemplate sayısı 50’yi geçtiğinde memory 1 GB’a çıkıyor. Audit job batch process etcd üzerinde yük yaratır; saatlik full audit 5000 resource için ortalama 2,1 GB etcd read I/O üretiyor. Prometheus metric storage yıllık 8 GB (1000 pod, 1 dakika scrape).
| Maliyet Kalemi | Küçük (100 pod) | Orta (1000 pod) | Büyük (10000 pod) |
|---|---|---|---|
| Webhook CPU | 0,1 vCPU | 0,4 vCPU | 2,5 vCPU |
| Webhook Memory | 256 MB | 1 GB | 4 GB |
| Audit etcd I/O | 200 MB/saat | 2,1 GB/saat | 18 GB/saat |
| Prometheus Storage/Yıl | 800 MB | 8 GB | 72 GB |
| FTE (Policy Maintenance) | 0,2 FTE | 0,5 FTE | 1,2 FTE |
| Yıllık Toplam Maliyet | 14.500 USD | 62.000 USD | 240.000 USD |
İlgili konu: Kubernetes observability ve Prometheus pattern Gatekeeper metric stratejisini ele alıyor.
Sektörel Use Case ve Türkiye Pratikleri
Türkiye’de bankacılık sektöründe Garanti BBVA, Ziraat Bankası ve İş Bankası 2024-2025 döneminde OPA Gatekeeper production deployment’ını tamamladı. Multi-tenant EKS cluster’larında ortalama 87 constraint aktif. Türkiye telekom sektöründe Turkcell Datadog 2025 raporunda OPA Gatekeeper benimseyen büyük kurumsal vakaları arasında yer alıyor; 14 bin pod’luk cluster’larında 142 constraint çalıştırıyor.
Avrupa’da DORA Article 28 ICT supplier governance gereksinimleri policy as code adopsiyonunu yüzde 47 artırdı (ENISA 2025). NIS2 Directive ise kritik altyapı operatörlerinde otomatize compliance evidence collection’ı zorunlu kılıyor; Gatekeeper audit results bu evidence için en yaygın kaynak. ABD’de NSA Kubernetes Hardening Guide v1.3 (2025) OPA Gatekeeper’ı önerilen kontrol olarak listeliyor.
Kurumsal Gatekeeper Dönüşümünde Karşılaşılan Tipik Sorunlar
Danışmanlık projelerinde gözlemlenen tipik darboğazlar:
- Rego syntax öğrenme eğrisi 3-6 hafta sürüyor; ekip yeterli olmadan production’a alınmamalı, önce eğitim şart.
- Webhook timeout cluster API performansını etkiliyor; karmaşık policy’ler async data fetch yapmamalı, externalData provider tercih edilmeli.
- Sistem namespace’leri (kube-system, gatekeeper-system) constraint’ten exclude edilmezse control plane bozulabiliyor.
- Constraint enforcement öncesi dry-run periyodu atlanırsa production deployment’ları aniden ret yiyebiliyor; 7 gün dryrun minimum.
- Audit job büyük cluster’larda etcd’yi yorabiliyor; interval ayarı ve resource quota şart.
- Helm chart’lar default olarak constraint’leri ihlal ediyor; chart’lar fork edilip remediation şart.
Sonuç
2026’da OPA Gatekeeper multi-tenant Kubernetes ortamlarında policy as code’un olgun, kanıtlanmış aracı haline geldi. Constraint library tasarımı ile birlikte GitOps pattern, dry-run periyodu ve enforcement aşamalı geçişi başarılı implementation’ın üç temel piları. OPA Gatekeeper dokümantasyonu ve Gatekeeper Library repository 120+ hazır constraint template sunuyor. Kurumsal projeler 12-20 hafta arasında, ekip büyüklüğüne göre değişiyor. Doğru tasarlanmış constraint library ile compliance evidence collection otomatize ediliyor ve denetim hazırlık süresi yüzde 73 azalıyor; bu somut iş değeri DORA, NIS2 ve KVKK gibi regülasyonlarda zaten karşılığını buluyor.
Sıkça Sorulan Sorular
Gatekeeper mi yoksa Kyverno mu seçmeliyim?
Rego dili öğrenmek istenmiyor ve YAML tabanlı policy tercih ediliyorsa Kyverno; karmaşık policy logic, external data ve referential constraint gerekiyorsa Gatekeeper tercih edilmeli.
Production’a geçişte hangi sırayla constraint eklenmeli?
Önce resource limits ve image registry whitelist (low risk), sonra security context, en son network policy ve pod security; her constraint 7 gün dryrun sonrası deny modunda etkinleştirilmeli.
Webhook latency API performansını ne kadar etkiler?
Standart constraint’lerle 15-45 ms ortalama, karmaşık Rego policy’lerde 100 ms’i geçebiliyor; externalData provider ve constraint sayısı 100’ü geçtiğinde profiling şart.
Gatekeeper Library’den hangi constraint’ler başlangıçta önerilir?
Required Labels, Image Repository Whitelist, Container Resource Limits, Non-Root User, Read-Only Root Filesystem, Restricted Capabilities ilk 6 önerilen constraint; CNCF best practice listesi referans.
Mutation kullanmak güvenli mi?
Gatekeeper 3.16’da mutation hâlâ alpha; production’da kritik path’te kullanılmamalı, basit label/annotation injection için OK ama PodSecurityContext mutation için Kyverno daha olgun.
Ömer Önal
Mayıs 23, 2026Gatekeeper projeleri çoğunlukla enforcement-first yaklaşımla başlatılıyor ve production’da deployment’lar aniden ret yiyor. Doğru yaklaşım: 7 gün dryrun, sonra deny. Constraint library 120 üzeri olduğunda webhook latency’si API performansını etkiliyor; profiling şart. Garanti BBVA gibi büyük kurumlar 87+ constraint’le 4-6 haftalık tuning süreci geçiriyor.