Kubernetes’te pod silmek neden containment sayılmaz

Kubernetes’te şüpheli pod’u silen güvenlik otomasyonu açığı kapatmıyor, çünkü ReplicaSet aynı image’dan aynı açığı taşıyan yeni bir pod başlatıyor ve silinen pod’la birlikte forensic kanıt da gidiyor. Yazı, agentic SOC (Security Operations Center) araçlarının Kubernetes’te aldığı müdahale aksiyonlarının diğer production değişiklikleriyle aynı incelemeden geçmesini savunuyor. Argo CD self-heal’ın, cluster’a doğrudan eklenen acil NetworkPolicy kısıtlamalarını geri alabileceğini de belirtiyor.

Agentic SOC nedir?

Agentic SOC, alarmların incelenmesini ve bazı müdahale adımlarını yapay zekâ agent’larına devreden bir güvenlik operasyon merkezi yaklaşımıdır. Agent’lar alarmı bağlam bilgisiyle araştırır, önceden tanımlı aksiyonları belirli sınırlar içinde çalıştırır. Kural tabanlı playbook’larla çalışan SOAR araçlarının yerine veya yanında kullanılır.

Pod silmek alarmı kapatır, açığı kapatmaz

Bir pod’u silmek Deployment’ın desired state’ini değiştirmez. ReplicaSet aynı image’dan, aynı güvenlik açığıyla yenisini başlatır. Elinizden giden tek şey container’ın filesystem’i ve runtime durumu olur.

Yazıdaki iki sayı tabloyu netleştiriyor. Container’ların yüzde 60’ı bir dakika veya daha kısa yaşıyor. Red Hat’in 2024 anketinde katılımcıların yüzde 45’i son 12 ayda runtime olayı bildirmiş. Ömrü bir dakikalık bir iş yükünde silme işlemi, saldırgana yalnızca bir kesinti sinyali gönderir.

Güvenlik aracı production’a değişiklik yapıyor, ama bu değişiklik deploy’larınızın geçtiği incelemeden geçmiyor. Google’ın SRE kitabı kesintilerin yaklaşık yüzde 70’ini canlı sistemdeki değişikliklere bağlıyor ve güvenlik otomasyonu da bu yüzdenin içinde.

Güvenlik otomasyonu önce cluster’a sormalı

Müdahaleden önce cevaplanması gereken soruların kaydı cluster’da ve Git’te zaten duruyor. Güvenlik ürününde ayrıca envanter tutmanıza gerek yok:

• OwnerReferences: pod’un sahibi hangi ReplicaSet, onun arkasında hangi Deployment var?
• Git ve Argo CD geçmişi: şüpheli process bir rollout’un hemen ardından mı başladı?
• HostNetwork: true ise pod, node’un network namespace’ini paylaşır ve pod seviyesindeki NetworkPolicy onu beklendiği gibi izole etmez.
• Service account ve cloud workload identity bağlantıları: pod hangi yetkileri taşıyor? Credential çalındıysa pod’u silmek onu iptal etmez.

Elle triage yaparken bu alanları birkaç saniyede okuyabilirsiniz:

kubectl get pod <pod> -n <ns> -o jsonpath='{.metadata.ownerReferences[*].name}'
kubectl get pod <pod> -n <ns> -o jsonpath='{.spec.hostNetwork}'
kubectl get pod <pod> -n <ns> -o jsonpath='{.spec.serviceAccountName}'
kubectl get ns <ns> --show-labels

Namespace label’ları sorumlu ekibi ancak güncel tutuluyorsa gösterir. Label’lar eskiyse otomasyon yanlış kişiye haber verir.

Argo CD self-heal acil kuralı geri alabilir

Argo CD’nin yönettiği bir NetworkPolicy’yi doğrudan cluster’da değiştirirseniz Git ile drift oluşur. Application’da otomatik self-heal açıksa Argo CD Git’teki tanımı geri yükler ve acil kısıtlama siz fark etmeden kalkar. Hangi uygulamada otomatik sync açık, önce buna bakın:

kubectl get application <app> -n argocd -o jsonpath='{.spec.syncPolicy.automated}'

Argo CD farklı bir namespace’te kuruluysa komuttaki namespace’i değiştirin. Çıktıda selfHeal true görüyorsanız o uygulamanın kaynaklarına cluster içinden yapılan her değişiklik geçicidir.

Yönetilen kaynaklarda kısıtlamayı Git’e commit edin veya Git güncellenene kadar onaylı bir acil prosedürle yerinde tutun. Argo CD’nin yönetmediği bir deny-all NetworkPolicy genelde dokunulmadan kalır, ama bu resource ownership ve pruning ayarlarınıza bağlı. Deny-all ancak CNI plugin’iniz NetworkPolicy uyguluyorsa işe yarar. Service selector’ındaki label’ı değiştirmek de yeni trafiği keser, açık bağlantıları ve pod’a doğrudan erişimi kesmeyebilir.

Ayrı bir izolasyon politikası açtıysanız bir sahibi olsun. Olay kapandığında onu kimin kaldıracağını runbook’a yazın.

Hangi aksiyon onaysız çalışabilir

Sysdig’in 2025 araştırması saldırı penceresini yaklaşık 10 dakika veriyor; olgun ekipler yaklaşık 3,5 dakikada müdahaleye başlıyor. Onay süreci saldırıdan uzun sürerse containment anlamını yitirir. Bu yüzden aksiyonları önceden sınıflandırın:

• Kanıt toplama: otomatik çalışabilir.
• Node cordon: yeni pod’ların o node’a planlanmasını durdurur, çalışan iş yüklerine dokunmaz. Öncesinde cluster kapasitesine bakılmalı, özellikle bir deployment sürerken.
• Credential rotation: birden fazla production servisi aynı credential’ı kullanıyorsa etki analizi ve sistem sahibinin onayı gerekir.

Her aksiyonun log’unda onayı kimin verdiği ve otomasyonun tam olarak ne yaptığı görünmeli.

Bu yazı incelemeyi agentic, müdahaleyi deterministik tutmayı öneriyor. Agent bağlamı toplar ve yorumlar; aksiyon ise önceden tanımlı, sınırları onaylanmış bir adım olarak çalışır. Bu sınırları SecOps platform ekibiyle birlikte yazmalı.

Production’daki otomasyonu geriye doğru okuyun

Yeni bir araca geçmeden önce production’da çalışan bir otomasyonu seçin. Son tetiklendiği alarmda elinde hangi bilgi vardı, hangi komutu çalıştırdı? Pod’un sahibi olan Deployment’ı kontrol etti mi? Araç Argo CD’nin yönettiği bir kaynağı değiştirdiyse self-heal’i düşündünüz mü?

Cevaplardan biri hayırsa, o aksiyonu platform ekibinin deploy’lara uyguladığı review gate’e bağlayın ve otomatik çalışma yetkisini yalnızca kanıt toplamaya indirin.