Vaka Çalışması: Kubernetes Güvenlik İncelemesinde Lateral Movement Zinciri

NDA kapsamındaki bir angajmandan anonimleştirilmiştir. Sistem: üretim e-ticaret altyapısını çalıştıran yönetilen Kubernetes kümesi.

Soru: Tek Pod'dan Küme Geneline?

Müşterinin sorusu netti: "Bir container imajında zafiyet bulunsun ve bir pod ele geçirilsin — saldırgan tüm kümeye yayılabilir mi?"

Bu, yapılandırma taramasının cevaplayamayacağı bir sorudur. Cevap için zinciri gerçekten kurmak gerekir.

Zincirin Halkaları

1. Aşırı Yetkili Servis Hesabı (Yüksek)

Uygulama pod'ları, get, list, watch yetkileriyle küme genelinde secrets okuyabilen bir servis hesabı kullanıyordu. Gerekçe "kolaylık"tı — tek hesap tüm ortamlarda çalışıyordu.

İstismar: Ele geçirilen pod'dan:

kubectl auth can-i --list          # küme genelinde secrets/list ✓
kubectl get secrets -A             # 40+ secret erişilebilir

2. GitOps Kimlik Bilgisi Secret İçinde (Kritik)

Erişilen secret'lar arasında GitOps aracının cluster-admin yetkili Git kimlik bilgisi düz metin duruyordu. Bu, tek halka ile Git deposundan küme geneline yazma yetkisi demek.

3. CI/CD Pipeline'ında Uzun Ömürlü Token (Yüksek)

Deploy pipeline'ı, süresi dolmayan bir kubeconfig token kullanıyordu. Token, pipeline sunucusundan sızdığında (veya çalışanından) küme erişimi kalıcıydı.

Kanıtlanan Saldırı Yolu

Zafiyetli pod → aşırı yetkili SA → GitOps secret okuma
→ cluster-admin Git kimlik bilgisi → istenen namespace'e zararlı workload
→ kalıcı küme erişimi

Her halka ekranda kanıtlandı; küme değiştirilmedi, yalnızca izole test namespace'inde doğrulama yapıldı.

Düzeltme Önceliği ve Yeniden Test

Öncelik	Düzeltme	Yeniden test
P0	GitOps kimlik bilgisi secret dışına (OIDC tabanlı kısa ömürlü token)	Secret okuma ile Git erişimi koparıldı ✓
P0	Servis hesabı bazlı RBAC: pod'lar yalnızca kendi namespace'inde sınırlı secret okur	Küme geneli listeleme 403 ✓
P1	Pipeline token'ı kısa ömre geçirildi + audit alarmı	Süresi dolmuş token reddi ✓
P2	Pod Security Standards (restricted) zorunlu	Ayrıcalık yükseltme yolu kapandı ✓

Küme Sıkılaştırma Kontrol Listesi

• Uygulama servis hesapları küme geneli secret okuyabilir mi?
• GitOps/CI kimlik bilgileri Kubernetes Secret'ında düz metin mi?
• Token'lar süresiz mi?
• Pod Security Standards uygulandı mı?
• RBAC değişiklikleri audit log ile izleniyor mu?

Bu kontrol listesi tarama düzeyindedir; zincirleme doğrulama için gerçek istismar gerekir.

Angajman Zaman Çizelgesi

Gün	Faz	Çıktı
1-2	Küme envanteri	RBAC haritası, servis hesabı matrisi, ağ politikası analizi
3-4	Kimlik katmanı	SA yetki denetimi, secret erişim matrisi, token yaşam döngüsü
5-6	Zincir kurulumu	Test namespace'inde izole istismar zinciri
7-8	CI/CD ve GitOps	Pipeline kimlik bilgisi akışı, GitOps yetki analizi
9-10	Kanıt ve rapor	Zincir video kanıtı, önceliklendirilmiş düzeltme planı
11-12	Teslim + düzeltme desteği	Platform ekibiyle eşzamanlı çalışma
13-14	Yeniden test	Düzeltme doğrulaması, kapanış

Zincirin tam kanıtı 6. günde hazırlandı. Platform ekibiyle aynı kanalda çalışıldığı için P0 düzeltmeler rapordan önce başladı — bulgu ile düzeltme arasında geçen süre, bulgunun gerçek değerini belirler.

RBAC Denetiminde Pratik Komutlar

Bu angajmanda kullanılan denetim adımları, kendi kümenizde çalıştırabileceğiniz karşılıklarla:

1. Servis hesabı gerçekten ne yapabilir?

kubectl auth can-i --list --as=system:serviceaccount:<ns>:<sa>

Beklenti: uygulama SA'sı yalnızca kendi namespace'inde sınırlı fiiller. secrets üzerinde get/list ve özellikle * fiilleri kırmızı bayrak.

2. Kim küme geneli secret okuyabilir?

kubectl get clusterrolebindings -o json | \
  jq '[.items[] | select(.roleRef.name | test("admin|cluster")) | .subjects]'

Uygulama SA'larının cluster-admin bağlarında görünmesi, bu vakadaki 2. halkanın habercisidir.

3. Token yaşam döngüsü ne durumda?

Uzun ömürlü statik token'lar (Secret içindeki service-account token'ları), bound token mekanizmasına geçilmemiş demektir. v1.24+ sürümlerde varsayılan olarak kısa ömürlü, hedef kitle bağlı token'lar üretilir — eski statik token'ların varlığı geçiş eksikliğini gösterir.

4. Pod Security Standards uygulandı mı?

kubectl get ns <ns> --show-labels | grep pod-security

enforce=restricted etiketinin yokluğu, privileged pod çalıştırma kapısının açık olduğu anlamına gelir.

Tespit Tarafı: Bu Zincir Alarm Verir miydi?

1. Secret okuma anomalisi: Bir pod'un normalde okumadığı namespace'lerdeki secret'lara erişim denemesi, API server audit log'unda görünür. Audit log + kural seti (Falco, audit policy) olmadan görünmez. Öneri: SA başına secret erişim taban çizgisi; sapmada alarm.

2. Yeni SA token kullanımı: Ele geçirilen pod'dan token ile yapılan API çağrıları, normal pod trafiğinden coğrafi/şebeke olarak ayrışabilir. Managed kümelerde control-plane log'larının SIEM'e akıtılması bu tespitin ön koşuludur.

3. GitOps değişikliği kaynağı: GitOps reposunda beklenmedik kaynaktan (insan değil, ele geçirilmiş credential) gelen commit, deploy öncesi yakalanabilir: commit imza doğrulaması + merge kuralı.

Zincirin hiçbir halkası bu müşteride anlık alarm üretmemişti — tespit altyapısı, düzeltmelerle birlikte kuruldu.

Bulgu ↔ Eşik: Neden Tarayıcı Bu Zinciri Görmez?

Araç	Görür mü	Neden
Zaafiyet tarayıcı	Hayır	RBAC ve secret yerleşimi "zafiyet imzası" değildir
CIS benchmark taraması	Kısmen	Aşırı yetkili SA'yı işaretleyebilir ama zinciri hesaplamaz
Konfigürasyon denetimi	Kısmen	Tek tek bulguları listeler, birleşik etkiyi vermez
Offensif doğrulama	Evet	Zinciri gerçekten kurar, etkiyi kanıtlar

CIS benchmark "aşırı yetkili servis hesabı" bulgusu, yönetim gündeminde P3'tür. Aynı bulgunun "cluster-admin GitOps credential'ına açılan kapı" olarak kanıtlanması, P0'dır. Fark, bulgunun değil bağlamın değeridir.

Sık Sorulan Sorular

Kubernetes güvenlik incelemesi ne sıklıkla yapılmalı?

Yapısal değişikliklerde (sürüm yükseltme, yeni cluster, GitOps aracı değişimi) mutlaka; stabil kümelerde yıllık offensive doğrulama iyi uygulamadır. RBAC ve secret yerleşimi sürekli kayan bir yüzeydir — tarama sürekli, derin doğrulama periyodiktir.

Yönetilen kümede (EKS/GKE/AKS) pentest izni gerekiyor mu?

Evet — sağlayıcıların kabul politikaları vardır ve genelde kendi kümeniz üzerinde, koşullarla izinli test yapılabilir. Control-plane testleri ve sağlayıcı altyapısı kapsam dışıdır. Angajman öncesi sağlayıcının kabul politikası kontrol edilmeli ve test penceresi belgelenmelidir.

Pod Security Standards yeterli mi?

PSS, pod seviyesinde ayrıcalık yükseltmeyi kapatır ama RBAC aşırı yetkilendirmesini ve secret yerleşim hatalarını çözmez. Bu vakadaki zincir, PSS uygulansa bile çalışırdı — çünkü halkalar RBAC ve credential yerleşimindeydi. PSS gerekli ama tek başına yetersiz bir katmandır.

Pilot Kapsam Talebi

Kümenizin lateral movement dayanıklılığını doğrulamak için görüşme talep edin.