Rego ile politika yazmak: karar mantığını koda taşımak

Politika kodu nedir, OPA ne yapar?

Politika kodu (policy as code), güvenlik ve uyum kurallarının belgelerde değil, çalıştırılabilir kod olarak tanımlanmasıdır. Kural 'üretimde yalnızca onaylı kayıt defterinden imaj çalışır' biçiminde bir cümle olarak durmaz; her dağıtımda otomatik olarak değerlendirilen bir karar mantığına dönüşür. Böylece denetim sonradan değil, kapı noktasında gerçekleşir ve kural sürüm kontrolünde incelenebilir hâle gelir.

Open Policy Agent (OPA), bu karar mantığını uygulamadan ayıran genel amaçlı bir politika motorudur. Servis bir karar gerektiğinde OPA'ya bir girdi (input) belgesi gönderir, OPA bu girdiyi yüklü politikalar ve verilerle değerlendirip karar döndürür. Karar yalnızca izin ya da ret olmak zorunda değildir; ihlal mesajlarının listesi de olabilir. Politikalar Rego adlı bildirimsel dille yazılır.

Önemli bir ayrım: OPA kararı üretir, kararı uygulamak çağıran sistemin işidir. Kubernetes API sunucusu, pipeline adımı ya da bir servis kapısı OPA'dan gelen yanıta göre isteği kabul veya reddeder.

Rego'nun temel yapıları

Rego, resmî belgede anlatıldığı üzere bir kuralın gövdesindeki ifadelerin tümünün sağlanmasını arar. Başlıca yapılar şunlardır: • Varsayılan değer: bir kural hiçbir koşulda tanımlanamazsa dönecek değeri verir. Örneğin varsayılan olarak izin vermemek için default allow := false yazılır • Koşullu kural: allow if { ... } gövdedeki ifadelerin hepsi doğruysa kural geçerli olur • Küme kuralı: deny contains msg if { ... } aynı adlı birden çok kural tanımının birleşimi olarak ihlal mesajlarını toplar • Girdi ve veri: input çağrıyla birlikte gelen belgedir, data ise OPA'ya yüklenmiş saklı belgelerdir; yalnız bu adlar ayrılmış sözcüktür • Yineleme: some x in koleksiyon ile elemanlar üzerinde dolaşılır, every ile tüm elemanların koşulu sağladığı doğrulanır

Rego'da her ifade bir atama değil bir sorgudur; bu yüzden alışılmış programlama dillerinden farklı düşünmek gerekir. Bir kural aynı anda birçok girdi için değerlendirilir. Bir eleman koşulu sağlamazsa ilgili ifade tanımsız olur ve kural o yoldan geçerlilik kazanmaz. 'Not' ile bir koşulun sağlanmadığı durum sınanır.

Sürüme göre bazı anahtar sözcüklerin (if, contains, in, every) ayrı bir içe aktarma ile açılması gerekebilir. Kendi OPA sürümünüzün belgesinde hangi sözdiziminin varsayılan olduğunu kontrol edin.

Örnek: Kubernetes için imaj kaydı kuralı

Kubernetes ile entegrasyonda API sunucusu bir admission isteğini OPA'ya webhook olarak gönderir. Resmî belgeye göre girdi bir AdmissionReview belgesidir; politika için ilgili alanlar input.request.kind, input.request.operation, input.request.userInfo, input.request.object ve güncellemelerde input.request.oldObject alanlarıdır. Belge ayrıca birden çok admission denetleyicisi olduğunda herhangi birinin reddetmesi hâlinde isteğin reddedildiğini belirtir.

Belgedeki örneğin yönünden esinlenen, onaylı olmayan kayıt defterinden gelen imajı reddeden basit bir kural:

package kubernetes.admission

deny contains msg if { some container in input.request.object.spec.containers not startswith(container.image, "registry.example.com/") msg := sprintf("%v: imaj onaylı kayıt defterinden gelmiyor", [container.name]) }

Kural, istekteki her konteyneri dolaşır; imaj adı onaylı kayıt defteri önekiyle başlamıyorsa bir ihlal mesajı üretir. Resmî örnek hem Pod'larda spec.containers hem de iş yükü şablonlarında spec.template.spec.containers altına bakar; gerçek bir politika bu yolların hepsini kapsamalıdır. Kubernetes için belge, OPA Gatekeeper'ı önerilen yol olarak gösterir; yalın OPA ile kube-mgmt ise karar kayıtları ve paketler gibi OPA'nın yönetim özelliklerine ihtiyaç duyulduğunda alternatiftir.

Politikayı test etmek

Politika koduna kod gibi davranmanın gereği, onu test etmektir. Rego testleri adı test_ ile başlayan kurallardır; belge, bunları '_test' ile biten ayrı bir pakette tutmayı önerir. Testte with input as ifadesiyle sahte girdi verilir. Yukarıdaki kural için bir test:

package kubernetes.admission_test

import data.kubernetes.admission

test_onaysiz_imaj_reddedilir if { admission.deny["web: imaj onaylı kayıt defterinden gelmiyor"] with input as {"request": {"object": {"spec": {"containers": [{"name": "web", "image": "docker.io/web"}]}}}} }

test_onayli_imaj_gecer if { admission.deny == set() with input as {"request": {"object": {"spec": {"containers": [{"name": "web", "image": "registry.example.com/web"}]}}}} }

Testleri opa test . komutuyla çalıştırırsınız; bu komut verilen dizinde tüm test kurallarını bulur. Ek bayraklar işe yarar: -v ayrıntılı çıktı verir, --run ile belirli testler seçilir, --fail-on-empty hiç test koşmadığında komutu başarısız yapar ve CI'da yanlış yazılmış test adlarını yakalar, --coverage ise hangi satırların hiç değerlendirilmediğini raporlar.

İyi bir test seti her kural için hem izin verilen hem reddedilen girdiyi, ayrıca sınır durumlarını içerir: boş konteyner listesi, eksik alan, beklenmeyen tür.

Pipeline'a, altyapı koduna ve istisnalara yerleştirmek

Politika Kubernetes ile sınırlı değildir. Aynı motor altyapı kodu planlarını (örneğin bir değişiklik planının JSON çıktısını), pipeline adımlarını ve servis yetkilendirmesini değerlendirebilir. Burada kural şudur: politikayı kontrol noktası olarak, hata mesajını ise geliştiriciye yol gösteren bir açıklama olarak tasarlayın. 'Reddedildi' mesajı yerine 'şu kaynakta şifreleme kapalı, şu alanı açın' mesajı geliştirici zamanından tasarruf eder.

Kurumsal ölçekte şu konular öne çıkar: • Sürümleme: politika repoda tutulur, değişiklikler kod incelemesinden geçer, yayına alınmadan önce testlerden geçer • İstisna yönetimi: bazı iş yükleri kuralın dışında kalmalıdır; istisnayı koda gömmek yerine veri olarak, sahibi ve bitiş tarihiyle tutmak denetimi kolaylaştırır • Kademeli devreye alma: yeni kuralı önce yalnızca raporlayan modda koşturup etkisini görmek, sonra bloklayıcı moda geçmek üretimdeki sürprizleri önler

Karar kayıtlarının tutulması ayrıca önemlidir. Hangi isteğin hangi nedenle reddedildiği sonradan görülebilirse, hem geliştirici sorularını yanıtlamak hem uyum denetimine kanıt sunmak kolaylaşır.

Sık yapılan hatalar

Başlangıçta en sık düşülen tuzaklar şunlardır: • Varsayılan reddi unutmak: kural hiçbir koşulda eşleşmezse sistemin izin mi ret mi vereceği açık olmalıdır • Tanımsızlığı yanlış okumak: eksik bir alan kuralı sessizce atlatabilir, bu yüzden 'alan yoksa ihlal say' gibi durumlar ayrıca düşünülmelidir • Test yazmamak: kural çalışıyor göründüğü hâlde bir girdi biçiminde sessizce kaçak verir • Aşırı sıkı başlamak: ilk günden bloklayıcı kural, ekibi politikaya karşı tutum almaya iter • Politikayı bir güvenlik ekibinin kapalı kutusu yapmak: geliştiriciler kuralı okuyamıyorsa çözemez • Girdi şemasını bilmeden yazmak: gerçek bir admission isteği örneğini kaydedip testlerde kullanın

Başlamak için tek bir net kural seçin, örneğin onaylı kayıt defteri ya da zorunlu etiket. Bunu test edin, raporlama modunda yayına alın, sonuçları ekiple gözden geçirin ve ancak ondan sonra blokajı açın.

Mindset programlarında bu beceriyi nerede çalışırsınız?

Mindset kataloğundaki Policy as Code Uygulamaları (OPA, Sentinel) programı, güvenlik ve uyum kurallarını manuel denetim yerine otomatik kapılarla uygulamak isteyen platform, güvenlik ve yönetişim ekipleri için tasarlanmıştır. Program politika kodu yaklaşımı ve karar mimarisi ile başlar; Rego dili temelleri, Kubernetes admission kontrolü, altyapı kodu ve pipeline denetimi modüllerinden geçer, test, sürümleme ve istisna yönetimi ile kurumsal devreye alma ve raporlama modüllerini kapsar.

Kurumsal ekipler için uygulanabilir yanı, güvenlik ve platform ekiplerinin aynı politika deposu üzerinde çalışma alışkanlığı kazanmasıdır: kural tanımı güvenlikte, uygulaması platformda kalırken ortak test ve istisna süreci kurulur. Konteyner tarafını derinleştirmek isteyenler için Konteyner ve Kubernetes Güvenliği programı tamamlayıcıdır.