Copilot'un Kubernetes manifestı şema doğrulamasından geçti ama 21 güvenlik bulgusu taşıyordu

GitHub Copilot tarafından üretilen bir Kubernetes manifestı, tek bir uyarı olmadan şema doğrulamasından geçti; ama bir policy tarayıcı aynı dosyada 21 güvenlik bulgusu tespit etti. dev.to'daki bir yazıda belgelenen bu olay, "bu dosya iyi biçimlendirilmiş" ile "bu iş yükü çalıştırılmaya güvenli" arasındaki uçurumun kompakt bir örneği.

Yazar, Copilot'tan bir Deployment manifestı istedi. Çıktı geçerli bir YAML idi ve kubeconform, katı Kubernetes şemasına uyduğunu hiç itiraz etmeden onayladı. Policy taraması ise bambaşka bir hikâye anlatıyordu: yirmi bir bulgu, hiçbiri bir şema kontrolünün ortaya çıkarabileceği türden değildi. Yazarın ifadesiyle YAML sorun değildi; sorun, tarif ettiği Deployment'dı.

Doğrulama ve inceleme farklı işlerdir

Yapısal bir doğrulayıcı biçimi denetler, niyeti değil. Yazıda belirtildiği gibi kubeconform bir container'ın image alanının string olduğunu onaylayabilir; ama o container'ın root olarak çalışıp çalışmadığı hakkında hiçbir fikri yoktur. Her iki araç da tam olarak tasarlandığı gibi çalıştı; yalnızca biri incelemeye benzeyen bir şey yaptı. Tavsiye, hızlı şema kontrolünü pre-commit hook olarak ve policy taramasını CI içinde olacak şekilde ikisini birlikte çalıştırmak.

Üretilen manifestlarda neler eksik

Yazıya göre Copilot'un manifestları neredeyse her seferinde üç şeyden yoksun:

• Health probe'lar — readinessProbe, livenessProbe veya startupProbe yok.
• Kaynak talepleri ve limitleri — request'i olmayan bir pod herhangi bir yere planlanabilir ve tahliye sırasında ilk sıradadır.
• securityContext — runAsNonRoot yok, allowPrivilegeEscalation: false yok, readOnlyRootFilesystem yok, düşürülmüş capability'ler yok.

Yazarın görüşüne göre bu üç eksiklik öz olarak incelemenin tamamıdır: üretilmiş bir manifestta başka hiçbir şeye bakmayacaksanız bunlara bakın. Yazıya göre restricted moduna ayarlanmış Pod Security Admission'a sahip bir namespace, böyle bir podu admission anında reddedecektir — ve sorunu fark etmek için inceleme anından çok daha iyi bir andır bu.

Ortak probe arıza modu

Yazı, kendi başına dikkat hak eden ince bir hatayı öne çıkarıyor: üretilen manifestlar sık sık liveness ve readiness probe'larını aynı endpoint'e bağlıyor. Üç probe farklı sorulara cevap verir — süreç açılışını tamamladı mı, şu anda trafik almalı mı ve toparlanamayacak kadar kilitlendi mi, yeniden başlatılmaya değer mi. Ortak bir health endpoint'i veritabanını kontrol ediyorsa ve veritabanı yavaşlarsa, tüm podlar aynı anda liveness'ı kaybeder; Kubernetes de bir olayın ortasında podları rotasyondan çıkarıp toparlanmalarına izin vermek yerine tüm deployment'ı yeniden başlatır.

Pipeline'daki iki tuzak

Yazar iki operasyonel tuzağa da dikkat çekiyor. Birincisi, kubectl apply --dry-run=client çevrimdışı bir kontrol değildir: OpenAPI şemasını API sunucusundan çeker ve erişilebilir bir cluster olmadığında tamamen başarısız olur; bu da onu cluster kimlik bilgisi olmayan bir pipeline için yanlış araç yapar — kubeconform bu rolü doldurur. İkinclisi, her komuttan önce kubectl config current-context çalıştırmak, staging için üretilmiş bir komutun production'a düşmesine karşı korur; bu risk AI'dan önce de vardı ama üretilen komutların ne kadar hızlı yapıştırıldığıyla büyüyor.

Copilot'un gerçekten işe yaradığı yer

Yazıya göre Copilot'un bu alandaki gücü manifest üretmek değil, onları açıklamak — devralınmış bir chart'a yönlendirip belirli bir bloğun ne yaptığını veya bir probe'un neden belirli bir şekilde yapılandırıldığını netleştirmek. Mekanik dönüşümleri de iyi halleder: bir Deployment'ı StatefulSet'e dönüştürmek, bir init container eklemek veya bir Kustomize overlay'i genişletmek gibi. Örüntü şu: model, cevabın yalnızca girdiden çıkabildiği yerlerde güçlü, cevabın cluster'ınızın gerçekte nasıl olduğuna bağlı olduğu yerlerde zayıf.

Kuralları kalıcı kılmak

Yazar, her prompt'ta gereksinimleri yeniden yazmak yerine bunları bir .github/copilot-instructions.md dosyasında tutuyor: her container'da kaynaklar, eksiksiz securityContext seti (runAsNonRoot, allowPrivilegeEscalation: false, readOnlyRootFilesystem, drop ALL), tag yerine digest ile sabitlenmiş image'lar ve farklı endpoint'lere bakan üç probe. Kalıcı talimatlar, modelin sahip olmadığı bilgiyi sağlayarak her istekte geri dönen sonucu değiştirir — yeniden prompt yazmak bunu hiçbir zaman yapmaz. Yazı, manifestları ve policy testlerini içeren bir depoya ve daha uzun bir yazıya bağlantı veriyor.

Neden önemli

AI destekli operasyon, inceleme pratiklerinin uyum sağlama hızından daha hızlı benimseniyor. Şema açısından temiz çıktılar yeşil pipeline'lar ve yanlış bir güven üretir; öte yandan spesifik eksiklikler — root container'lar, eksik limitler, ortak probe'lar — tam da yavaş bir bağımlılığı tam bir kesintiye dönüştüren şeylerdir. Ders Kubernetes'in ötesine genellenir: Terraform ya da OpenAPI için olsun, her yapısal doğrulayıcı bir policy motorundan farklı bir soruya cevap verir. Kalıcı koruma bariyerleri policy-as-code, admission control ve kalıcı model talimatlarında olmalıdır; prompt başına dikkatlilikte değil.