AI Destekli Yazılım Geliştirmede Politika-as-Code ile Güvenli Akış

AI destekli yazılım geliştirmede denetim sınırını doğru kurmak

Generative AI veya bir kod ajanı tarafından üretilen pull request'i tüm repository yerine değişen teslimat artefaktları üzerinden değerlendirin. İlk kontrolü geliştirici makinesinde değişen dosya kapsamı ile başlatmak, örneğin yalnızca k8s/, infra/ ve Dockerfile değiştiğinde politika kapısını çalıştırmak için somut bir sınır verir:

git diff --name-only origin/main...HEAD | grep -E '^(k8s/|infra/|Dockerfile)'\nconftest test k8s/ -p policy/

Buradaki mekanizma önemlidir: modelin uygulama koduna eklediği bir endpoint, dağıtım manifestine hostPath veya latest etiketi eklemedikçe aynı kontrol sınıfına girmez. Bu ayrım, politika sonucunu daha anlaşılır yapar ve CI süresini gereksiz yere her dosya için artırmaz.

Politikayı prompt metnine veya ajanın 'başarılı' bildirimine bağlamayın. Denetim girdisi, Git'e yazılmış YAML, Dockerfile ve Terraform planı olmalıdır; çünkü LLM çıktısı ile gerçekte commit edilen diff farklı olabilir. Örneğin bir Git hook ile üretilen manifesti normalize edip politikaya gönderebilirsiniz:

kustomize build k8s/overlays/staging > /tmp/rendered.yaml\nyq eval 'sort_keys(..)' /tmp/rendered.yaml > /tmp/rendered.sorted.yaml\nconftest test /tmp/rendered.sorted.yaml -p policy/

Kustomize render edilmeden yapılan denetim, base içindeki güvenli ayarın overlay tarafından ezilmesi gibi yaygın bir edge case'i kaçırır.

Generative AI çıktısı için Rego ile uygulanabilir teslimat kuralları

Open Policy Agent ve Conftest ile Kubernetes kaynaklarını doğrudan değerlendirin. Aşağıdaki Rego politikası, izin verilen registry dışındaki imajları ve sürümsüz latest etiketini reddeder. Bu iki kontrol birlikte gerekir: sadece registry kontrolü, kurum registry'sindeki mutable latest imajını; sadece tag kontrolü ise dış registry'den çekilen sabit digest'i gözden kaçırır.

package delivery\n\ndeny[msg] {\n  input.kind == "Deployment"\n  c := input.spec.template.spec.containers[_]\n  not startswith(c.image, "registry.example.com/")\n  msg := sprintf("unapproved registry: %s", [c.image])\n}\n\ndeny[msg] {\n  input.kind == "Deployment"\n  c := input.spec.template.spec.containers[_]\n  endswith(c.image, ":latest")\n  msg := sprintf("mutable image tag: %s", [c.image])\n}

Bu dosyayı policy/delivery.rego altında tutup conftest test k8s/ -p policy/ komutunu CI'da çalıştırın.

Kuralın kendisi de test edilmelidir. policy/delivery_test.rego içine hem izinli digest hem reddedilen registry senaryosu ekleyin ve opa test policy/ -v çalıştırın. Özellikle image alanı Helm template'inde boş bırakılıp daha sonra values dosyasından geliyorsa, Conftest'e template değil Helm render çıktısını verin:

helm template api charts/api -f env/prod.yaml > /tmp/api.yaml\nopa eval --format pretty --data policy --input /tmp/api.yaml 'data.delivery.deny'

Aksi halde politika yalnızca {{ .Values.image }} metnini görür ve gerçek registry kararını veremez.

ci cd pipeline içinde plan ve manifest kapılarını sıralamak

Bir ci cd pipeline içinde önce format ve render, sonra statik politika, en son sağlayıcıya erişen plan adımını çalıştırın. Render başarısızsa Terraform planı başlatmamak, hatayı üretildiği katmanda tutar. Aşağıdaki GitHub Actions örneğinde Conftest hem render edilmiş Kubernetes YAML'ını hem de Terraform'un JSON planını ayrı policy paketleriyle değerlendirir:

name: delivery-policy\non: [pull_request]\npermissions:\n  contents: read\njobs:\n  verify:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v4\n      - run: helm template api charts/api -f env/staging.yaml > rendered.yaml\n      - run: conftest test rendered.yaml -p policy/kubernetes\n      - run: terraform -chdir=infra init -backend=false\n      - run: terraform -chdir=infra plan -out=tfplan\n      - run: terraform -chdir=infra show -json tfplan > ../tfplan.json\n      - run: conftest test tfplan.json -p policy/terraform

Gerçek ortam kimlik bilgilerini plan aşamasına vermek zorundaysanız, uzun ömürlü secret yerine iş yükü kimliğiyle kısa ömürlü token alın ve pull request fork'larında bu işi çalıştırmayın.

CI kaynağına göre diff tabanlı atlama yaparken politika dosyası değişimini istisna sayın. Örneğin yalnızca docs/ değiştiğinde deploy-policy işi atlanabilir, fakat policy/ altında bir dosya değiştiğinde k8s/ değişmemiş olsa bile test zorunlu olmalıdır. GitHub CLI ile bunu görünür bir kontrol haline getirebilirsiniz:

git diff --name-only origin/main...HEAD > changed.txt\nif grep -q '^policy/' changed.txt; then\n  opa test policy/ -v\nfi

Bu ayrıntı, bir PR'nin politikayı gevşetip aynı PR'de yasaklı manifest eklemesi durumunda yalnızca manifest-path filtresine güvenilmesini engeller.

Terraform, infrastructure as code ve cloud native mimari için plan denetimi

Terraform kaynağını HCL metni üzerinden değil, terraform show -json çıktısındaki resource_changes üzerinden denetleyin. HCL'deki değişken çözülmemiş olabilir; plan JSON'u ise değişikliğin create, update veya delete eylemini ve hesaplanan değerleri ayırır. Aşağıdaki kural, AWS tarafında public-read ACL ile oluşturulacak S3 bucket'ını merge aşamasında reddeder:

package terraform\n\ndeny[msg] {\n  r := input.resource_changes[_]\n  r.type == "aws_s3_bucket"\n  r.change.actions[_] == "create"\n  r.change.after.acl == "public-read"\n  msg := sprintf("public ACL forbidden: %s", [r.address])\n}

Aynı model AWS eğitimi veya Google Cloud eğitimi laboratuvarlarında da uygulanabilir; sağlayıcıya özgü resource type'ları ayrı paketlerde tutmak, ortak tag ve şifreleme politikalarını ise ortak bir Rego paketiyle çağırmak daha yönetilebilirdir.

Plan JSON'unda bilinmeyen değerler after_unknown altında gelir. Sadece change.after kontrol etmek, örneğin modül çıktısından gelen CIDR veya image digest için karar veremediğiniz halde geçiş izni verebilir. Kritik internet erişimi kurallarında bilinmeyeni reddeden ek bir koşul koyun ve nedenini hata mesajına yazın:

deny[msg] {\n  r := input.resource_changes[_]\n  r.type == "aws_security_group_rule"\n  r.change.after_unknown.cidr_blocks\n  msg := sprintf("unknown CIDR requires explicit review: %s", [r.address])\n}

Bu yaklaşım cloud native mimari içinde container orchestration katmanını da korur: Kubernetes namespace veya ağ politikası Terraform modülünden geliyorsa, deploy anındaki admission kontrolüne ek olarak plan zamanında değişiklik görünür olur.

Docker eğitimi, Kubernetes eğitimi ve yerel politika laboratuvarı

Uygulanabilir bir yazılım eğitimi veya teknoloji eğitimi modülü için yerel kümede admission denetimini yeniden üretin. Docker eğitimi kapsamında uygulamayı digest ile paketleyin, Kubernetes eğitimi kapsamında Gatekeeper yerine ilk aşamada Conftest ile aynı manifesti doğrulayın ve minikube üzerinde sonucu gözlemleyin:

minikube start\ndocker build -t registry.example.com/api:dev .\nhelm template api charts/api -f env/dev.yaml | conftest test -p policy/kubernetes -\nkubectl apply -f k8s/

Yerel image'ın minikube daemon'unda görünmesi gerekiyorsa minikube image load registry.example.com/api:dev kullanın; host Docker daemon'ına build edip doğrudan cluster'ın image cache'inde var saymak sık yapılan bir hatadır.

Yapay zeka eğitimi, yapay zeka kursu, vibe coding eğitimi, vibe coding kursu ve llm eğitimi katılımcılarına aynı laboratuvarda bir LLM'den Deployment ile Terraform değişikliği üretmesini, ardından en az bir politikayı bilinçli olarak ihlal etmesini isteyin. DevOps eğitimi için teslim ölçütü, sadece çalışan uygulama değil, opa test policy/ -v, conftest test rendered.yaml -p policy/kubernetes ve terraform show -json tfplan artefaktlarının PR'a eklenmesidir. Böylece ai destekli yazılım geliştirme pratiği, üretim kodu ile policy-as-code kararının aynı değişiklik setinde incelendiği bir egzersize dönüşür.

Sık Sorulan Sorular

AI destekli yazılım geliştirme için ci cd pipeline içinde OPA nerede çalışmalı?

OPA veya Conftest'i manifest render işleminden sonra, deploy işleminden önce çalıştırın. Kubernetes için helm template veya kustomize build çıktısını; Terraform için terraform show -json tfplan çıktısını girdi yapın. policy/ değiştiğinde ayrıca opa test policy/ -v zorunlu olmalıdır.

Terraform ve infrastructure as code denetiminde HCL yerine plan JSON neden kullanılmalı?

Plan JSON, değişkenlerin ve modüllerin çözülmüş resource_changes listesini içerir. Reddedilecek bir karar için change.actions, change.after ve after_unknown alanlarını birlikte kontrol edin. Bilinmeyen CIDR, image veya rol değerlerini kritik kaynaklarda açık incelemeye yönlendirmek için after_unknown koşulu ekleyin.

Kubernetes eğitimi ve minikube laboratuvarında policy-as-code nasıl test edilir?

minikube start komutundan sonra Helm chart'ını helm template ile render edin ve çıktıyı stdin üzerinden conftest test -p policy/kubernetes - komutuna verin. Test geçen manifesti kubectl apply ile uygulayın; yerel Docker imajı kullanılıyorsa minikube image load ile cluster runtime'ına aktarın.

Vibe coding kursu için generative AI ile üretilen Dockerfile nasıl sınırlandırılır?

CI'da Dockerfile için Trivy config ve Hadolint, deploy manifesti için Conftest çalıştırın. Örneğin hadolint Dockerfile && trivy config --exit-code 1 . komutlarıyla Dockerfile sorunlarını, ardından helm template çıktısındaki registry ve latest etiketini Rego ile ayrı aşamada reddedin.