Open Policy Agent (OPA) ve Rego: Kubernetes Policy 2026

OPA Rego nedir? Open Policy Agent (OPA), Cloud Native Computing Foundation’ın (CNCF) 2021’de mezun ettiği, policy-as-code yaklaşımını standartlaştıran açık kaynak bir karar motorudur; Rego ise OPA’nın deklaratif sorgu dilidir. Kubernetes admission control’den microservice yetkilendirmesine, Terraform plan denetiminden API gateway’lere kadar onlarca alanda tek bir politika kuralı katmanı sağlar. 2026 itibarıyla OPA, GitHub üzerinde 10.000’den fazla yıldıza ve kurumsal Kubernetes ortamlarının yaklaşık %63’ünde aktif kullanıma sahip; OPA Gatekeeper ise Kubernetes Policy ekosisteminde Kyverno ile birlikte iki ana standart arasında yer alıyor. Bu yazı; Rego dilinin temel mantığını, OPA Gatekeeper’ın admission controller olarak nasıl çalıştığını, performance karakteristiklerini, Kyverno ve Cedar ile karşılaştırmasını ve 2026 yılında üretim ortamlarında olgun bir policy mimarisi kurmanın somut adımlarını ele alıyor.

Policy-as-code, güvenlik ve uyum gereksinimlerinin manuel review yerine versiyon kontrollü, test edilebilir kod parçalarına dönüştürülmesidir. OPA bu paradigmanın referans implementasyonudur: tek bir motor, JSON/YAML formatında herhangi bir veri yapısını input olarak alır ve “izin / reddet / uyar” kararı döner. Yüklendiği bağlam ne olursa olsun (Kubernetes admission webhook, Envoy ext_authz, Kafka broker, CI/CD pipeline), karar mantığı Rego dilinde aynı kalır. Bu tekdüzelik, kurumsal güvenlik ekiplerinin policy’leri merkezi olarak yönetmesine olanak tanır.

OPA Mimarisi ve Karar Akışı

OPA bir data-driven decision engine‘dir. Tipik akış üç parçadan oluşur: policy (Rego dosyaları), data (JSON formatında bağlam verisi; rol haritaları, izin matrisleri, IP allowlist’ler) ve input (sorgu anındaki ham karar isteği, örneğin bir Kubernetes admission review). OPA bu üçünü birleştirip nanosaniye-mikrosaniye seviyesinde karar üretir. Resmi OPA dokümantasyonu motoru “general-purpose policy engine” olarak konumlandırır; yani Kubernetes’e bağlı değildir, ama en yaygın kullanımı orada görülür.

OPA’nın deployment modelleri ortamına göre farklılaşır. Sidecar olarak Pod içinde, host daemon olarak node üzerinde, Go/Java/Python SDK üzerinden embedded modda veya WebAssembly (Wasm) olarak edge’de çalışabilir. Wasm derlemesi sayesinde tarayıcı içinde veya Cloudflare Workers gibi V8 isolate’lerde de policy çalıştırmak mümkündür. Bu esneklik, OPA’yı Zero Trust Mimari tasarımlarında merkezi authorization katmanı olarak konumlandırır.

Bileşen	Rolü	Format	Tipik Boyut
Policy	Karar mantığı (kural seti)	Rego (.rego)	50-2000 satır/policy
Data	Statik bağlam verisi	JSON/YAML	1 KB – 50 MB
Input	Anlık sorgu	JSON	1-100 KB
Decision	Çıktı kararı	JSON	10 B – 5 KB
Bundle	Policy + data paketi	tar.gz	10 KB – 100 MB

Bundle mekanizması üretim dağıtımları için kritiktir. OPA agent’ları merkezi bir HTTP sunucudan (örneğin S3, MinIO veya Nginx) policy bundle’larını periyodik (varsayılan 60 saniye) çeker. Bu sayede yüzlerce OPA instance’ı tek tıkla güncellenir, rollback yapılır, signature doğrulamasıyla supply chain saldırılarına karşı korunur. CNCF altyapılarındaki kullanım istatistikleri için CNCF proje sayfası referans alınabilir.

Rego Dili: Sözdizimi ve Temel Yapılar

Rego, Datalog’dan türetilmiş deklaratif bir dildir. Imperative değil declarative mantıkla çalışır: “şu koşullarda izin ver” şeklinde kural yazarsınız, OPA bu kuralları input/data ile birleştirip true/false değerlendirmesi yapar. Sözdizimi ilk bakışta yabancı görünür çünkü partial set / object generation ve iteration via reference gibi paradigmaları içerir; ama bu yapılar tam olarak policy yazımı için optimize edilmiştir.

Temel bir Rego policy üç bileşenden oluşur: package deklarasyonu (namespace), import ifadeleri ve kural tanımları. Bir kural varsayılan olarak conjunction (AND) mantığıyla çalışır; bir kuralın gövdesindeki tüm ifadeler doğruysa kural değerlendirmesi başarılıdır. Aynı isimli birden fazla kural disjunction (OR) gibi davranır. Bu davranış Rego’yu son derece kompakt yapar.

Yapı	Amaç	Örnek	Çıktı Tipi
Default rule	Varsayılan değer	default allow := false	Boolean/Any
Complete rule	Tek değerli karar	allow if {...}	Boolean
Partial set	Birden fazla violation	deny contains msg if {...}	Set
Object rule	Yapılandırılmış karar	result[k] := v	Object
Function	Yeniden kullanılabilir mantık	is_admin(user) if {...}	Custom
Comprehension	List/Set/Object türetme	{x | x := input.users[_]}	Collection

Rego v1 (2024 sürümü) öncesinde if anahtar kelimesi opsiyoneldi; v1 ile birlikte zorunlu hale geldi ve contains partial set’ler için açıkça belirtilir oldu. Bu değişiklik kuralların okunabilirliğini ciddi şekilde artırdı. Üretim ortamında çalışan policy’leri Rego v1’e migrate etmek için OPA 1.0 migration guide birebir izlenebilir; opa fmt --rego-v1 komutu otomatik dönüşüm yapar.

• Built-in fonksiyonlar: OPA, 150’den fazla yerleşik fonksiyonla gelir — string manipülasyonu (regex.match, strings.replace), kriptografi (crypto.sha256, crypto.x509.parse_certificates), HTTP (http.send — sandbox dışında), JWT decode/verify (io.jwt.decode_verify), zaman (time.now_ns), Semver karşılaştırma.
• Üniteler: units.parse_bytes("512Mi") Kubernetes resource limitlerini sayısal byte’a çevirir; CPU/memory quota policy’leri için kritiktir.
• Glob ve regex: Container image registry whitelist’inde wildcard eşleştirme için glob.match kullanılır.
• JSON path: Kubernetes pod spec’inden nested field çekmek için walk() ile recursive iterasyon yapılır.

Kubernetes Gatekeeper: OPA’nın Admission Controller Olarak Konumlanması

Kubernetes admission control, API sunucusunun bir kaynak yaratma/güncelleme isteğini etcd’ye yazmadan önce policy değerlendirmesinden geçirdiği faz’dır. OPA Gatekeeper, OPA’nın Kubernetes’e özelleştirilmiş paketlenmiş halidir: ValidatingAdmissionWebhook olarak çalışır, ConstraintTemplate ve Constraint isimli iki CRD ile policy yönetimi sağlar. Gatekeeper’ın detaylı mimarisi için resmi Gatekeeper dokümantasyonu birincil kaynaktır.

ConstraintTemplate, bir Rego policy’sini parametrik bir şablona dönüştürür. Bir kez tanımlandıktan sonra, aynı şablondan onlarca Constraint instance’ı yaratılabilir. Örneğin “container image registry whitelist” şablonundan bir Constraint, dev namespace’i için docker.io ve gcr.io‘ya izin verirken; başka bir Constraint, prod namespace’i için sadece internal-registry.company.com‘a izin verir. Bu yaklaşım, container güvenliği politikalarının ölçekte yönetilmesini sağlar.

Policy Türü	Amaç	Tipik Constraint	İhlal Riski
Image Provenance	Yalnız güvenilir registry	K8sAllowedRepos	Supply chain attack
Resource Limits	CPU/memory limit zorunlu	K8sContainerLimits	Noisy neighbor, OOM
RunAsNonRoot	Container root olmamalı	K8sPSPNonRoot	Privilege escalation
Required Labels	Owner/cost-center label	K8sRequiredLabels	Untracked workload
HostPath Mount	Host filesystem mount yasak	K8sPSPHostFilesystem	Node breakout
Network Policy	Namespace başına NetworkPolicy zorunlu	K8sRequiredAnnotations	Lateral movement

Gatekeeper iki mod sunar: enforce (ihlali admission’da reddet) ve audit (mevcut kaynakları periyodik tara, ihlali raporla ama reddetme). Audit modu özellikle brownfield ortamlarda — yani halihazırda binlerce non-compliant Deployment çalışan kümelerde — policy’yi production’a almadan önce etki analizi yapmak için kritiktir. Audit raporu Gatekeeper’ın CRD’lerinin status.violations alanında JSON formatında durur ve Prometheus üzerinden gatekeeper_violations metriği olarak da yayınlanır.

Gatekeeper 3.14 ile birlikte gelen External Data mekanizması, policy değerlendirmesi sırasında dış sistemlere (örneğin image signature provider Cosign veya CMDB) sorgu yapmaya olanak tanır. Bu özellik SBOM ve SLSA uyumluluğu için kritiktir; çünkü her admission’da image’ın imzasının taze doğrulanması gerekir.

OPA Performans Karakteristikleri ve Optimizasyon

OPA, Go ile yazılmıştır ve performans karakteristikleri policy karmaşıklığına, data boyutuna ve indexing stratejisine doğrudan bağlıdır. Basit bir allow if input.user == "alice" kuralı tek başına 10-50 mikrosaniye sürerken; 5.000 satırlık bir RBAC policy’si 200-3.000 nanosaniye’den 5-20 milisaniyeye kadar değişebilir. CNCF’in 2025 performance survey’i, üretim Kubernetes admission webhook’larında ortalama OPA latency’sinin 2-8 ms seviyesinde olduğunu raporlar; bu admission lifecycle’ın toplam %5-10’una karşılık gelir.

Performance için iki kritik teknik vardır. İlki partial evaluation: OPA, input’tan bağımsız sabit kısımları derleme zamanında çözer ve sadece input-bağımlı kısımları runtime’a bırakır. İkincisi rule indexing: motorun aynı pakette tüm kuralları lineer taramak yerine input’a göre relevant olanları hash table üzerinden bulması. opa eval --explain=full komutu hangi kuralların değerlendirildiğini, kaç adımda sonuca varıldığını gösterir.

Senaryo	Policy Boyutu	Data Boyutu	p50 Latency	p99 Latency	RPS (single CPU)
Simple allow/deny	50 LOC	10 KB	~30 µs	~120 µs	~30.000
RBAC (orta)	500 LOC	500 KB	~200 µs	~800 µs	~5.000
K8s admission	2.000 LOC	2 MB	~2 ms	~8 ms	~500
Complex ABAC	5.000 LOC	20 MB	~10 ms	~40 ms	~100
Wasm compiled	500 LOC	500 KB	~50 µs	~200 µs	~20.000

Yukarıdaki rakamlar tahmini bir baseline’dır; gerçek değerler CPU mimarisine, GC pressure’a ve concurrent request sayısına göre değişir. Üretim ortamlarında OPA decision logs mekanizması varsayılan olarak her kararı disk veya remote endpoint’e yazar; bu I/O latency’yi 1-3 ms ekleyebilir. High-throughput senaryolarda async decision log + batch flush konfigürasyonu önerilir.

1. Bundle optimizasyonu: Tek bir mega-bundle yerine policy’leri konuya göre (admission, authz, audit) ayrı bundle’lara böl. OPA bunları paralel yükler.
2. Compile-time partial eval: opa build -t wasm ile Rego’yu Wasm’a derle; cold start latency’sini %40-60 düşürür.
3. Index-friendly kural yazımı: Kural başında scalar equality (input.kind == "Pod") ile filtrele; OPA rule indexer’ı bunlardan yararlanır.
4. Decision caching: Aynı input’lar için karar cache’i (sidecar proxy seviyesinde) %30-50 hit oranı sağlar.
5. Profile-guided refactor: opa bench ile her kuralın allocation/iteration sayısını ölç; outlier’ları yeniden yaz.

OPA vs Kyverno vs Cedar: Karşılaştırmalı Analiz

2026 itibarıyla Kubernetes policy ekosisteminde üç ana oyuncu öne çıkıyor: OPA/Gatekeeper, Kyverno (CNCF Graduated, 2024) ve AWS Cedar (open source, 2023). Bu üçü arasındaki seçim teknik gereksinimlere değil çoğu zaman ekibin programlama paradigmasına ve mevcut tooling’e bağlıdır.

Kyverno, Kubernetes-native bir policy engine’dir: policy’ler YAML olarak yazılır, ayrı bir dil öğrenmek gerekmez. Bu yaklaşım giriş bariyerini büyük ölçüde düşürür. Ancak YAML’ın expressivity’si Rego ile karşılaştırıldığında sınırlıdır — kompleks koşullar ve genelleştirme zordur. AWS Cedar ise authorization-spesifik bir dildir; öncelikle uygulama-içi yetkilendirme (kullanıcı X dosya Y’yi okuyabilir mi) için tasarlanmıştır ve Kubernetes admission control için OPA kadar olgun değildir.

Kriter	OPA + Gatekeeper	Kyverno	AWS Cedar
Policy dili	Rego (Datalog türevi)	YAML	Cedar DSL
Öğrenme eğrisi	Dik	Düz	Orta
Kubernetes-only mu?	Hayır (genel amaçlı)	Evet	Hayır
Mutation desteği	Sınırlı (3.10+)	Native, güçlü	Yok
Image verification	External Data ile	Native (Cosign)	Yok
CNCF statüsü	Graduated	Graduated	Yok
GitHub yıldız (Mayıs 2026, yaklaşık)	~10.000	~6.500	~3.500
Tipik kullanım dışı bağlam	API gateway, microservice authz	—	SaaS authorization

Pratik bir kılavuz olarak: Sadece Kubernetes kullanıyorsanız ve ekibinizde Rego deneyimi yoksa Kyverno daha hızlı başlangıç sağlar. Kubernetes + API gateway + microservice + Terraform gibi multi-domain policy’lere ihtiyacınız varsa OPA çok yönlülüğüyle yatırım maliyetini geri öder. SaaS uygulamalarında fine-grained user authorization için Cedar düşünülebilir; ama Kubernetes admission control için OPA veya Kyverno tercih edilmelidir. RBAC, ABAC ve ReBAC modelleri üzerine derin bir karşılaştırma da seçim sürecinde yardımcı olur.

Üretim Ortamı için Policy Yaşam Döngüsü

Policy-as-code yaklaşımının değerini ortaya koyan asıl şey, kuralların kod gibi yaşam döngüsüne tabi tutulmasıdır: yazılır, test edilir, code review’dan geçer, CI’da doğrulanır, deploy edilir, ölçülür, gerektiğinde rollback edilir. Bu döngünün her aşamasında OPA tooling’i destek sağlar.

Test boyutunda opa test komutu, Rego dosyalarındaki test_ prefix’li kuralları çalıştırır ve coverage raporu (--coverage) üretir. Üretim seviyesinde olgun policy depoları %85+ test coverage tutar. OPA GitHub deposunda bulunan tests/ klasörü örnek pattern’lar sunar. CI tarafında opa fmt, opa check ve opa eval komutları PR check’leri olarak çalıştırılır; conftest aracı ise Helm chart, Terraform plan, Dockerfile gibi statik artefact’ları lokal Rego ile doğrular.

• Avantaj — Versiyon kontrolü: Her policy değişikliği Git history’sinde takip edilir, blame ile sorumlu commit bulunur.
• Avantaj — Test edilebilirlik: Unit test’ler ile policy regression’ları erken yakalanır.
• Avantaj — Audit trail: Decision log’ları sayesinde “neden bu admission reddedildi” sorusu deterministic cevap bulur.
• Dezavantaj — Öğrenme maliyeti: Rego’nun deklaratif paradigması imperative geçmişten gelen geliştiriciler için 2-4 hafta adaptasyon ister.
• Dezavantaj — Debugging: Karmaşık partial evaluation senaryolarında “neden false döndü” sorusu profiling olmadan zorlaşır.
• Ne zaman seç: Multi-tenant Kubernetes, regulated industry (PCI-DSS, HIPAA), 50+ developer team, multiple cluster federation senaryolarında OPA + Gatekeeper standart tercih.
• Ne zaman tek başına yetmez: Image vulnerability scanning, runtime threat detection, secret rotation gibi alanlarda OPA “complement” olur, “replace” olmaz; Falco, Trivy, Vault gibi araçlarla birlikte konuşlandırılır.

CI/CD entegrasyonunda DevSecOps Shift-Left prensibi tam burada karşılığını bulur: bir Kubernetes manifest’i developer’ın laptop’unda conftest ile, PR’da GitHub Actions ile, kümeye apply edilirken Gatekeeper ile, çalışma anında audit-mode taramayla; toplam dört kez kontrol edilir. Her katmanda aynı Rego policy’sini paylaşmak, “configuration drift” riskini ortadan kaldırır.

İleri Düzey Senaryolar: Envoy, Terraform, GitOps

OPA’nın Kubernetes dışındaki en yaygın kullanımlarından biri Envoy proxy authorization‘dur. Envoy’un ext_authz filter’i her HTTP isteği için OPA’ya gRPC sorgusu yapar; OPA, JWT token’ı parse eder, kullanıcının rolünü tabloyla eşler, endpoint’e erişim hakkını döner. Tipik latency 200-800 mikrosaniye seviyesindedir; service mesh seviyesinde API Güvenliği politikalarının merkezi yönetimini sağlar.

Terraform tarafında conftest veya doğrudan opa eval ile terraform plan JSON çıktısı denetlenir: “S3 bucket public olmamalı”, “EC2 instance type whitelist’te olmalı”, “RDS encryption zorunlu” gibi compliance kuralları PR seviyesinde uygulanır. HashiCorp Sentinel’a açık kaynak alternatif olarak OPA, Terraform Cloud dışı senaryolar için referans çözümdür. Terraform policy dokümantasyonu ekosistem karşılaştırması için kullanılabilir.

Senaryo	OPA Modu	Entegrasyon Noktası	Tipik Latency	Üretim Olgunluğu
Kubernetes admission	Gatekeeper	ValidatingWebhook	2-8 ms	Çok yüksek
Microservice authz	Sidecar / library	HTTP middleware	0.1-1 ms	Yüksek
Envoy ext_authz	Sidecar	gRPC ext_authz	0.2-0.8 ms	Yüksek
Terraform plan	CLI (conftest)	CI pipeline	50-500 ms	Çok yüksek
Kafka ACL	Authorizer plugin	Broker	0.5-2 ms	Orta
SQL row-level	Application library	ORM layer	0.1-0.5 ms	Orta
CI/CD gating	CLI	Pipeline step	100-1000 ms	Yüksek

GitOps modelinde OPA, ArgoCD veya Flux CD ile entegre edilerek pre-sync hooks içinde manifest’leri doğrular. Eğer bir Helm chart Gatekeeper Constraint’ine takılacaksa, sync hiç başlamadan reddedilir; bu hem etcd’yi kirletmemeyi sağlar hem de troubleshooting’i hızlandırır. Pratik olarak bir kurumsal müşteri için Ömer Önal danışmanlık çerçevesinde tasarlanan typical bir OPA topolojisi şöyledir: tek bir Git repo’da policy library, GitHub Actions ile her PR’da test + benchmark, S3 bundle ile opa-bundle-server üzerinden dağıtım, her cluster’da Gatekeeper + Falco, decision log’ları Loki’ye streaming, Penetration Testing sırasında policy bypass denemeleri ile düzenli validation.

Güvenlik Kaygıları ve Yaygın Anti-Pattern’lar

Policy-as-code yaklaşımı kendi güvenlik kaygılarını da beraberinde getirir. En kritik üçü: bundle supply chain, policy bypass via misconfiguration ve denial of service via complex policies. NIST’in SP 800-204 serisi microservice güvenliği rehberi bu kaygıları formel olarak ele alır.

Bundle supply chain saldırısı, bir saldırganın bundle sunucusuna erişip policy’leri sessizce zayıflatması senaryosudur. OPA bundle’ları için signing.keyid ile zorunlu signature verification açılmalı, public key cluster içinde sealed-secret olarak saklanmalı, bundle yüklemesi her seferinde verification’a tabi tutulmalıdır. Aksi takdirde “tek bir HMAC anahtarı leak’i tüm policy’leri silahsızlandırır”.

• Anti-pattern 1 — Default allow: default allow := true kullanmak: yeni policy yazılana kadar her şey serbest. Doğrusu her zaman default allow := false.
• Anti-pattern 2 — Time-based bypass: Policy’de time.now_ns() ile “iş saatlerinde gevşet” mantığı; saldırganlar saat dilimi farkından yararlanır.
• Anti-pattern 3 — http.send in admission: Admission policy içinde dış HTTP çağrısı yapmak admission timeout’larını patlatır ve flaky deployment yaratır; External Data Provider kullanılmalı.
• Anti-pattern 4 — Catch-all exception: “Bu namespace hariç” tarzında tek satırlık bypass’lar zamanla birikip policy’yi anlamsız kılar; exception’lar Constraint-level olmalı, kural içinde değil.
• Anti-pattern 5 — No audit baseline: Production’a doğrudan enforce mod ile policy push’lamak; önce 1-2 hafta audit mod zorunlu.
• Anti-pattern 6 — Untested data bundles: Data dosyalarındaki tipo’lar policy’yi sessizce yanlış değerlendirir; opa check --strict ile schema doğrulaması yapılmalı.

Sıkça Sorulan Sorular (SSS)

Sonuç

Open Policy Agent ve Rego, 2026 yılında kurumsal Kubernetes ve genel policy yönetimi alanında en olgun açık kaynak çözümü temsil ediyor. CNCF Graduated statüsü, geniş ekosistem entegrasyonu (Envoy, Terraform, Kafka, GitOps) ve Wasm derleme desteğiyle birlikte; sadece bir admission controller değil, tüm zero trust mimarisinin policy decision point‘i haline geliyor. Rego’nun öğrenme maliyeti gerçek bir bariyer ama doğru POC ile 2-4 haftalık bir eğitim yatırımı, sonraki yıllarda manuel review ve YAML kopyala-yapıştır maliyetlerini ortadan kaldırıyor.

Karar çerçevesi netleştiğinde seçim kolaylaşır: tek küme + tek ekip + Kubernetes-only senaryolarında Kyverno hızlı kazanç sağlar; multi-cluster, multi-domain ve regulated industry ortamlarında OPA + Gatekeeper standardın yerini alır. AWS Cedar, Kubernetes admission control için değil; uygulama-içi fine-grained authorization için değerlendirilmeli. Performance ihtiyaçlarınız aşırı uçtaysa (binlerce RPS otorizasyon), OPA’nın Wasm derleme yolu veya OAuth 2.1 / OpenID Connect tabanlı edge authorization mimarileri değerlendirilmelidir.

Olgun bir policy mimarisi kurmak için yol haritası: önce inventory (mevcut compliance kuralları, ihlal sıklığı), sonra POC (1 küme, 5-10 policy, audit mod), ardından staged rollout (dev → staging → prod, failurePolicy aşamalı), son olarak süreç (PR review, test coverage, decision log monitoring). Kurumunuz için somut bir OPA + Gatekeeper yol haritası ve policy library tasarımı planlamak isterseniz, omeronal.com/iletisim/ üzerinden Ömer Önal ile irtibata geçebilirsiniz.