AI Destekli Yazılım Geliştirmede Ajan Çalışma Alanı İzolasyonu

AI destekli yazılım geliştirme için tehdit modelini somutlaştırın

Bir generative ai kod ajanı için tehdit modeli, yalnızca hatalı kod üretimini değil ajan sürecinin erişebildiği varlıkları kapsamalıdır. İlk envanteri ajan konteynerında mount, id, env ve getent hosts komutlarıyla çıkarın; özellikle CI değişkenlerinden sızan erişim anahtarları, otomatik bağlanan ServiceAccount token'ı, Docker socket'i ve yazılabilir çalışma dizinlerini kaydedin. LLM eğitimi sırasında sık atlanan nokta şudur: modelin ürettiği komut güvenilir değildir, fakat komutu çalıştıran süreç gerçek IAM yetkileriyle hareket eder. Bu nedenle risk bir prompt kalitesi problemi değil, süreç yetkisi problemidir.

Ajanın gerekli yetkisini görev bazında tanımlayın. Örneğin yalnızca bir Go deposunda test çalıştıracak ajan için kabul edilebilir işlem kümesi git diff, go test, geçici /tmp yazımı ve paket proxy'sine HTTPS çıkışıdır; git push, kubectl, cloud CLI ve SSH istemcisi varsayılan imajda bulunmamalıdır. İmaj envanterini Syft ile ölçebilirsiniz: syft packages agent-image:sha-abc -o cyclonedx-json > sbom.json. SBOM içinde awscli, gcloud veya kubectl görünmesi doğrudan ihlal değildir, ancak her biri için görev gereksinimi ve çağrılabileceği ağ hedefi belgelenmelidir.

Docker eğitimi ve Kubernetes eğitimi: köksüz, salt okunur ajan pod'u

docker eğitimi örneklerinde görülen root kullanıcıyla çalışan geliştirme konteynerını üretime taşımayın. Aşağıdaki Pod, kök dosya sistemini salt okunur yapar, Linux capability listesini boşaltır, privilege escalation'ı kapatır ve yalnızca çalışma alanı ile geçici dizinleri emptyDir olarak yazılabilir bırakır. readOnlyRootFilesystem etkinleştirildiğinde npm, pip veya derleyicilerin önbellek yazdığı dizinler görünür hale gelir; HOME, TMPDIR ve ilgili cache dizinini açıkça bağlamazsanız ajan beklenmedik biçimde hata verir.

apiVersion: v1
kind: Pod
metadata:
  name: code-agent
spec:
  automountServiceAccountToken: false
  securityContext:
    runAsNonRoot: true
    runAsUser: 10001
    runAsGroup: 10001
    fsGroup: 10001
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: agent
    image: registry.example.com/agent@sha256:REPLACE_ME
    command: ["/app/agent"]
    env:
    - name: HOME
      value: /work/home
    - name: TMPDIR
      value: /work/tmp
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop: ["ALL"]
    resources:
      requests: { cpu: "500m", memory: "1Gi" }
      limits: { cpu: "2", memory: "2Gi", ephemeral-storage: "4Gi" }
    volumeMounts:
    - { name: workspace, mountPath: /workspace }
    - { name: work, mountPath: /work }
  volumes:
  - name: workspace
    emptyDir: {}
  - name: work
    emptyDir: { sizeLimit: 2Gi }

Bu manifesti önce minikube üzerinde gerçek davranışla sınayın: minikube start --driver=docker, ardından kubectl apply -f agent.yaml ve kubectl exec code-agent -- sh -c 'touch /etc/probe || true; id; mount | grep workspace' komutlarını çalıştırın. /etc/probe işlemi başarısız olmalı, uid 0 olmamalı ve /workspace yazılabilir görünmelidir. container orchestration katmanında yalnızca Pod Security Admission kullanmak yeterli değildir; admission denetimi manifesti kabul eder, fakat imaj içindeki araçları veya ağ erişimini sınırlandırmaz.

Cloud native mimari içinde ağ çıkışını allowlist ile kurun

Ajan pod'unun egress'ini kapatmak, yanlışlıkla kaynak kodun veya CI sırlarının dış bir hedefe POST edilmesini sınırlayan en etkili kontroldür. Kubernetes NetworkPolicy ancak CNI eklentiniz politikayı uyguluyorsa çalışır; örneğin bazı yerel kurulumlarda politika nesnesi kabul edilse de trafik fiilen engellenmez. Bu nedenle Calico veya Cilium belgelerindeki enforcement durumunu doğrulayın ve test pod'undan hem izinli hem yasaklı hedefe curl çalıştırın.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: agent-default-deny-egress
  namespace: agents
spec:
  podSelector:
    matchLabels:
      app: code-agent
  policyTypes: ["Egress"]
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - { protocol: UDP, port: 53 }
    - { protocol: TCP, port: 53 }
  - to:
    - ipBlock:
        cidr: 10.96.0.10/32
    ports:
    - { protocol: TCP, port: 443 }

Bu örnekte ikinci kural yalnızca iç paket proxy'sini temsil eder; doğrudan internet CIDR'lerini allowlist'e eklemek, CDN IP değişimleri nedeniyle kırılgan ve geniş bir yetki üretir. FQDN tabanlı kurallar gerekiyorsa Cilium FQDN policy veya egress gateway kullanın ve DNS TTL davranışını inceleyin. Doğrulama için kubectl exec -n agents deploy/code-agent -- curl -m 3 https://example.com zaman aşımına uğrarken, iç proxy isteği başarılı olmalıdır. Bu test, cloud native mimari tasarımında DNS'e izin verildiği halde HTTPS hedefinin yanlışlıkla açık kalmadığını kanıtlar.

Terraform ile kısa ömürlü bulut kimliği ve infrastructure as code

Ajan için kalıcı erişim anahtarı enjekte etmek yerine iş yükü kimliği kullanın. aws eğitimi veya google cloud eğitimi laboratuvarlarında bile erişim anahtarı içeren .env dosyaları yerine Kubernetes ServiceAccount ile bulut rolü arasında OIDC güven ilişkisi kurmak gerekir. Kritik ayrıntı, güven ilişkisindeki subject koşuludur: yalnızca doğru namespace ve ServiceAccount'a izin verilmezse aynı kümedeki başka bir pod ajan rolünü üstlenebilir.

resource "aws_iam_role" "agent" {
  name = "code-agent-read-artifacts"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Principal = { Federated = var.cluster_oidc_provider_arn }
      Action = "sts:AssumeRoleWithWebIdentity"
      Condition = {
        StringEquals = {
          "${var.oidc_issuer}:aud" = "sts.amazonaws.com"
          "${var.oidc_issuer}:sub" = "system:serviceaccount:agents:code-agent"
        }
      }
    }]
  })
}

resource "aws_iam_role_policy" "artifact_read" {
  role = aws_iam_role.agent.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Action = ["s3:GetObject"]
      Resource = ["arn:aws:s3:::build-artifacts-prod/agent-input/*"]
    }]
  })
}

Bu infrastructure as code değişikliğini bir ci cd pipeline içinde terraform fmt -check, terraform validate, terraform plan -out=tfplan ve OPA veya Conftest kuralı ile denetleyin. Örneğin rol politikasında s3:* veya Resource: * görülürse planı reddedin. Uygulama sonrasında pod içinden aws sts get-caller-identity ile varsayılan rolü doğrulayın; ardından izin dışı bir bucket için aws s3api get-object çağrısının AccessDenied vermesi, yalnızca planın değil gerçek çalışma zamanının da en az yetki ilkesine uyduğunu gösterir.

Vibe coding eğitimi için ölçülebilir sandbox maliyeti

vibe coding eğitimi ve vibe coding kursu içeriklerinde izolasyon çoğu zaman yavaşlıkla eş tutulur. Bunu varsaymak yerine aynı commit için iki koşulu ölçün: sınırsız geliştirme pod'u ve yukarıdaki kısıtlı pod. İmajı her iki denemeden önce node'a çekin, 30 tekrar yapın ve Pod oluşturma zamanını, ilk komut zamanını ve go test süresini ayrı kaydedin. kubectl get pod code-agent -o jsonpath='{.status.startTime}' yalnızca scheduler sonrası zamanı verir; uçtan uca süre için istemcide Unix epoch kaydedin ve OpenTelemetry span'ında sandbox.create, repo.clone ve test.run adlarını kullanın.

Kaynak limitlerini değiştirmek bir performans optimizasyonuysa önce-sonra karşılaştırması zorunludur. Örneğin CPU limiti 2 yerine 1 olduğunda test süresini k6 ile değil, iş yükünün gerçek komutuyla ölçün: hyperfine --warmup 3 --runs 20 'kubectl exec code-agent -- go test ./...'. p50, p95 ve başarısız deneme sayısını birlikte raporlayın. p95 yalnızca DNS politikası eklendikten sonra artıyorsa CNI egress kararlarını Cilium Hubble ile inceleyin; artış derleme CPU'sundan kaynaklanıyorsa pod CPU throttling değerini Prometheus'taki container_cpu_cfs_throttled_seconds_total metriğiyle ilişkilendirin.

Yazılım eğitimi müfredatında operasyonel pratikler

Bir yazılım eğitimi veya teknoloji eğitimi laboratuvarında katılımcıya yalnızca yapay zeka eğitimi ya da yapay zeka kursu kapsamında prompt yazdırmak yeterli değildir. Aynı görevde önce sınırsız bir pod ile /var/run/secrets/kubernetes.io/serviceaccount/token dosyasını kontrol ettirin, sonra automountServiceAccountToken: false içeren manifestle farkı doğrulatın. Bu pratik, ai destekli yazılım geliştirme kararlarının altyapı sınırları olmadan değerlendirilemeyeceğini somutlaştırır.

devops eğitimi programında docker eğitimi, kubernetes eğitimi, minikube, terraform ve ci cd pipeline uygulamalarını tek bir teslimatta birleştirin: katılımcı bir ajan imajı oluşturmalı, minikube üzerinde default-deny egress politikasını kanıtlamalı, Terraform planındaki geniş IAM yetkisini Conftest ile reddetmeli ve test ölçümlerini artifact olarak saklamalıdır. Böyle bir ödev, llm eğitimi alan geliştiricinin model çıktısını çalıştırmadan önce hangi kimlik, dosya sistemi ve ağ sınırlarının etkili olduğunu denetlemesini sağlar.

Sık Sorulan Sorular

AI destekli yazılım geliştirme ajanında Docker socket neden bağlanmamalı?

Docker socket'e yazabilen bir süreç, çoğu kurulumda host üzerinde ayrıcalıklı konteyner başlatabilir veya host dosya sistemini volume olarak bağlayabilir. Ajanın konteyner oluşturması gerekiyorsa socket paylaşmak yerine Kubernetes Job API için yalnızca gerekli namespace'e create yetkisi veren, kısa ömürlü bir ServiceAccount kullanın ve Job şablonunu admission policy ile sabitleyin.

Kubernetes eğitiminde minikube ile NetworkPolicy gerçekten test edilebilir mi?

Evet, ancak kullandığınız CNI'ın policy enforcement desteklediğini doğrulamanız gerekir. minikube profilinde Cilium veya Calico eklentisini etkinleştirin, ardından bir deny policy uygulayıp test pod'undan curl -m 3 https://example.com çalıştırın. Policy nesnesinin kubectl get networkpolicy çıktısında görünmesi tek başına trafik engellendiği anlamına gelmez.

Terraform ile infrastructure as code kullanırken ajan IAM rolü nasıl sınırlandırılır?

OIDC trust policy içinde hem audience hem de system:serviceaccount:namespace:serviceaccount subject değerini eşleştirin. Permission policy'de Action listesini GetObject gibi tekil API'lerle, Resource listesini de belirli bucket prefix'iyle sınırlandırın. terraform plan JSON'unu Conftest'e vererek Action: * veya Resource: * içeren Statement bloklarını pipeline'da hata olarak işaretleyin.

Vibe coding kursu için sandbox performansı hangi araçla ölçülmeli?

Pod başlatma ve görev adımlarını OpenTelemetry trace span'larıyla, komut süresini hyperfine ile, CPU kısıt etkisini Prometheus container_cpu_cfs_throttled_seconds_total metriğiyle ölçün. Aynı imaj digest'i, aynı commit ve önceden çekilmiş imaj koşullarında en az 20 tekrar yaparak p50 ve p95 değerlerini karşılaştırın.