Kubernetes Sızma Testi - Kubernetes kontrolleri gerçekten bir şeyleri engelliyor mu?

Kubernetes güvenlik testinin en yaygın hatası, bir kontrolün var olduğunu görmekle onun işlediğini kanıtlamayı karıştırmaktır. Bir NetworkPolicy nesnesi mevcuttur; ama trafiği gerçekten ayırıyor mu? Bir Pod Security etiketi görünür; fakat enforce mi yoksa yalnızca warn mı? Bir admission webhook’u tanımlıdır; peki erişilemez olduğunda isteği reddediyor mu, sessizce kabul mü ediyor?

Bu playbook’un tek bir temel ilkesi var: her testin işi, bir beyanı doğrulanmış bir karara çevirmektir. Etiket, politika ya da webhook görmek yalnızca ilk kanıttır; asıl kanıt, kararın güvenli bir test nesnesi üzerinde fiilen uygulandığının gösterilmesidir. Aşağıda, düşük yetkili bir başlangıç noktasından cluster etkisine giden yolun her halkasını keşiften kimlik ve yetkilendirmeye, admission’dan node güvenliğine hangi yöntemle test edeceğinizi bulacaksınız.

---

1. Testin amacı: hangi sorulara kanıtla cevap vermelisiniz?

Değerlendirmenin sonunda şu soruların her biri, tahminle değil kanıtla yanıtlanabilmelidir. Bir araştırmacı olarak testinizi bu sorular yönlendirir:

• Kümeye kimler, nereden ve hangi kimlikle erişebiliyor?
• Ele geçirilmiş düşük yetkili bir kimlik gerçekte ne yapabiliyor?
• Bir namespace’teki ihlal başka namespace’lere, control plane’e veya node’a sıçrayabilir mi?
• Güvensiz bir iş yükü oluşturulmak istendiğinde hangi katman bunu engelliyor?
• Secret’lar ve token’lar hangi yollarla açığa çıkabilir?
• Ağ politikaları yalnızca tanımlı mı, yoksa trafiği fiilen ayırıyor mu?
• Güvenilmeyen bir image çalıştırılabilir mi?
• Şüpheli davranış algılanıp anlamlı bir uyarı üretiyor mu?
• Test sırasında oluşturulan her şey eksiksiz geri alınabiliyor mu?

Her bulguyu, bu sorulardan birine verdiği yanıt üzerinden çerçeveleyin.

---

2. Önce yöntem: güvenli test modeli

Neyi test edeceğinizden önce nasıl test edeceğinizi netleştirmelisiniz. Offensive security’nin itibarı ne kadar ileri gidebildiğinizde değil, gerektiği yerde durabildiğinizde ölçülür.

2.1 Test seviyeleri (S0–S4)

Her faaliyet, üretime verdiği riske göre bir seviyeye oturur. Kapsamınızın izin verdiği en yüksek seviyeyi baştan yazılı olarak belirleyin.

S3 ve S4, varsayılan kapsamın parçası değildir. Üretimde gerçek secret okuma, gerçek token toplama, kalıcılık kurma, host’ta değişiklik yapma ve kontrolsüz kaynak tüketimi yapılmaz.

2.2 “İlk güvenli kanıtta dur” kuralı

Bir zincirin riskini göstermek için onu sonuna kadar sömürmeniz gerekmez. Mümkün olan en düşük etkili kanıt yeterlidir:

• Secret erişiminde: gerçek değer yerine önceden yerleştirilmiş bir canary değerinin okunması.
• Komut çalıştırmada: yalnızca kimlik ve çalışma bağlamının (whoami düzeyinde) gösterilmesi.
• Host erişiminde: dosya içeriği yerine, onaylı ve zararsız bir canary dosyasının varlığının doğrulanması.
• Ağ erişiminde: uygulama verisi yerine test uç noktasından sabit bir yanıt alınması.
• Yetki yükseltmede: kalıcı yönetici bağı kurmak yerine, API kararının sunucu tarafı dry-run veya geçici kapsamla doğrulanması.

Kanıt elde edildiği an zincir durur. Erişim elde etmiş olmak, daha fazla veri okumak için bir izin değildir.

2.3 Durdurma koşulları

Şunlardan biri görülürse test durdurulup ilgili taraflara haber verilir: üretim iş yükünde beklenmeyen yeniden başlama/gecikme/hata artışı; test namespace’i dışına yanlışlıkla yazma; gerçek iş verisi veya üretim token’ıyla karşılaşma; güvenlik kontrolünün test trafiğini gerçek saldırı sanıp otomatik müdahale başlatması; geri dönüş adımının çalışmaması; kapsam dışı bir sisteme geçiş ihtimali.

2.4 Test namespace’i standardı

Yazma gerektiren her kontrol için ayrı ve süreli bir namespace kullanın. Üzerinde en az şunlar bulunmalı: benzersiz çalışma kimliği, sorumlu kişi, otomatik sona erme zamanı, üretim-dışı veri etiketi, varsayılan reddetme (default-deny) ağ politikası, kaynak kotası ve en kısıtlı Pod Security profili.

Engellenmesi beklenen bir manifesti önce dry-run ile değerlendirin. Gerçek oluşturma, ancak dry-run yeterli kanıt üretmiyorsa ve S2/S3 onayı varsa yapılır.

---

3. Kanıt modeli: bulguyu nasıl kaydedersiniz?

Ekran görüntüsü tek başına zayıf kanıttır. Her test için şu şablonu doldurun:

Test ID:
Zaman (UTC):
Test seviyesi (S0–S4):
Test kimliği / principal:
Gönderilen istek veya incelenen alan:
Beklenen güvenli sonuç:
Gözlenen sonuç:
Karar: PASS / FAIL / PARTIAL / BLOCKED / N/A
Kanıt özeti veya hash'i:
Olası etki:
Geri dönüş adımı ve doğrulaması:

Hassas değerler kanıta düz metin yazılmaz: secret’lar tamamen maskelenir; yalnızca tür, kaynak referansı, uzunluk ve gerekiyorsa tek yönlü özet tutulur. Token, sertifika özel anahtarı ve registry kimlik bilgileri hiçbir rapora eklenmez.

Sonuç durumları: PASS (güvenli davranış gösterildi), FAIL (risk güvenli biçimde doğrulandı), PARTIAL (bazı katmanlar koruyor, bazıları yalnızca uyarı üretiyor), BLOCKED (yetki/erişim/pencere nedeniyle test edilemedi), N/A (mimari gereği uygulanabilir değil, gerekçesiyle). Unutmayın: BLOCKED, PASS değildir. Test edemediğiniz alan raporda görünür kalmalıdır.

---

4. Uçtan uca test akışı

Bundan sonrası, güven sınırı sınırı ilerleyen asıl playbook. Her başlıkta ne test edilir, nasıl güvenli doğrulanır, beklenen güvenli sonuç ve bulgu ölçütü birlikte verilir.

Aşama 0 Güven sınırlarını çıkarın

Komuttan önce harita gelir. Amaç envanter değil; “hangi kimlik hangi güven sınırını geçebiliyor?” sorusuna cevap veren tek sayfalık bir güven sınırı diyagramıdır. Üzerine şunları yerleştirin: API erişim yolları ve yönetim ağları; kimlik sağlayıcı ve grup eşlemeleri; namespace/tenant sınırları; ingress-egress-servisler arası trafik; node havuzları; registry ve dağıtım zinciri; secret kaynakları ve workload identity; audit/olay/alarm akışı; yedekleme bileşenleri.

Bu harita, ilerideki her bulgunun şiddetini belirleyecek referanstır.

Aşama 1 Salt okunur keşif (S1)

Aşama 2 API ve control plane erişim yüzeyi

K8S-API-01 Ağ erişim sınırı. API uç noktasının internetten, kurumsal ağdan ve iş yükü ağından erişilebilirliğini ayrı ayrı ölçün; izin verilen kaynak ağların gerçekten daraltıldığını, TLS güven zincirinin geçerli olduğunu doğrulayın. Beklenen: API yalnızca tanımlı yönetim yollarından erişilebilir. Bulgu: gereksiz genel erişim, geniş kaynak ağı, doğrulanamayan sertifika.

K8S-API-02 Anonim erişim. Kimliksiz isteklerin /api, /apis, sürüm, sağlık ve kaynak uç noktalarına verdiği yanıtları karşılaştırın; system:anonymous ve system:unauthenticated yetkilerini inceleyin. Beklenen: hassas kaynaklar için 401/403, yalnızca bilinçli açılmış minimum sağlık bilgisi. Bulgu: namespace/pod/log/metrik/yapılandırma verisinin kimliksiz alınabilmesi.

K8S-API-03 TLS ve istemci kimliği. Eski protokoller, zayıf şifre takımları, süresi dolmuş sertifikalar ve istemci sertifikalarının paylaşımlı kullanım riskini değerlendirin. Bulgu: uzun ömürlü/paylaşımlı yönetici sertifikası, yönetilmeyen sertifika yaşam döngüsü.

K8S-API-04 Audit kapsamı. Kimlik doğrulama hataları, RBAC retleri, secret erişimleri, exec/attach/port-forward, RBAC değişiklikleri ve admission kararlarının kayda girdiğini doğrulayın; logların değiştirilemez veya ayrı güven alanına aktarılmış olduğunu arayın. Bulgu: kritik olayın kaydedilmemesi veya kullanıcıya kadar izlenememesi.

Aşama 3 Kimlik doğrulama ve RBAC

RBAC’te rol adlarına bakmak yetmez; rol, binding, grup üyeliği, aggregated role ve impersonation birlikte çözülmelidir.

K8S-RBAC-01 Etkin yetki matrisi. En az şu principal’lar için matris çıkarın: salt okunur kullanıcı, geliştirici, namespace yöneticisi, dağıtım otomasyonu, operatör/controller service account’u, node kimliği, acil durum yöneticisi, kimliksiz kullanıcı. Matris fiil × kaynak × alt kaynak × namespace düzeyinde olmalı ve şu satırları ayrı içermelidir: pods/exec, pods/attach, pods/portforward, pods/ephemeralcontainers, secrets, serviceaccounts/token, roles/rolebindings, clusterroles/clusterrolebindings, certificatesigningrequests, nodes/proxy, impersonate, escalate, bind.

K8S-RBAC-02 Wildcard roller. * fiil/kaynak/API grubu kullanan kuralları bulun; birden fazla düşük riskli iznin birleşerek yüksek etki üretip üretmediğini değerlendirin. Bulgu: iş ihtiyacıyla açıklanamayan wildcard.

K8S-RBAC-03 Dolaylı yetki yükseltme. Buradaki asıl mesele, tekil yetkinin değil bileşimin riskidir:

Nasıl güvenli doğrulanır: yalnızca test namespace’i ve düşük etkili geçici bir service account kullanın; kabul edilip edilmeyeceğini dry-run ile ölçün. Yönetici yetkisini kalıcı olarak bağlamayın.

K8S-RBAC-04 Unutulmuş bağlar. Varsayılan SA kullanım oranı, silinmiş ekipleri gösteren binding’ler, doğrudan kullanıcı bağları, acil durum yetkilerinin süre/onay mekanizması ve sistem gruplarına yanlışlıkla verilen roller.

K8S-RBAC-05 Token yaşam döngüsü. Gerekmeyen pod’larda otomatik token mount kapalı olmalı; kısa ömürlü, audience sınırlı, döndürülebilir token aranmalı; token’ın log/env/volume’a sızmadığı kontrol edilmeli. Güvenli doğrulama: yalnızca sentetik SA ve süreli token; gerçek token kanıta alınmaz.

Aşama 4 Admission ve politika uygulama

K8S-ADM-01 Pod Security profilleri. Her uygulama namespace’inde enforce/warn/audit etiketlerini inceleyin; profil sürümünün sabit mi güncel mi izlendiğini kaydedin. Bulgu: yalnızca audit/warn kullanımı, profil yokluğu, geniş istisna.

K8S-ADM-02 Gerçek engelleme testi. İzole namespace’te, aşağıdaki her bir özelliği taşıyan minimal manifestleri ayrı ayrı ve önce dry-run ile gönderin tek manifeste birçok ihlal koyarsanız hangi kontrolün karar verdiği anlaşılmaz:

• privileged: true
• allowPrivilegeEscalation: true
• root kullanıcı
• host network / PID / IPC
• hostPath
• tehlikeli Linux capability ekleme
• kısıtlanmamış seccomp
• izin verilmeyen image kaynağı veya mutable tag

K8S-ADM-03 Fail-open ve kör noktalar. Şunları test edin: admission bileşeni erişilemezken istek kabul mü ediliyor (fail-open) yoksa reddedilyor mu (fail-closed)? Namespace/object selector kaynaklı kör noktalar var mı? CREATE ile UPDATE/PATCH davranışı farklı mı? Pod yerine controller nesnesi gönderilince politika değişiyor mu? Ephemeral container ve alt kaynaklar kapsanıyor mu? Beklenen: kritik politikalar fail-closed davranır ve eşdeğer iş yükü oluşturma yollarını tutarlı kapsar.

K8S-ADM-04 İstisna yönetimi. Her istisnanın sahibi, gerekçesi, dar kapsamı ve sona erme tarihi olmalı; süresi dolanlar yeniden test edilmeli.

Aşama 5 Pod ve container güvenliği

Her kontrolü hem mevcut manifestlerde salt okunur arayın, hem de admission katmanında yeni bir ihlalin engellenip engellenmediğiyle eşleştirin.

Kontrollü doğrulama sınırı: HostPath veya privileged kabulünü doğrulamanız gerekiyorsa, testi yalnızca ayrılmış node havuzunda yapın; host root diskini mount etmeyin, gerçek host dosyalarını okumayın, kalıcılık denemeyin. Önceden hazırlanmış, hassas olmayan bir canary yoluna erişim yeterli kanıttır.

Aşama 6 Secret ve yapılandırma güvenliği

K8S-SEC-01 Erişim grafiği. Hangi kullanıcı/grup/SA/controller’ın hangi secret’a erişebildiğini çıkarın; list ve watch fiillerinin toplu veri etkisini ayrıca değerlendirin; iş yükü oluşturabilen bir kimliğin dolaylı olarak başka SA’nın secret’ına ulaşma ihtimalini hesaba katın.

K8S-SEC-02 Kullanım şekli. Hassas değerlerin manifest, ConfigMap, annotation, command argument veya env’e yazılmadığını doğrulayın; volume ile sunulan secret’ın dosya izinlerini, mount yolunu ve log’a yansıma riskini inceleyin.

K8S-SEC-03 At-rest ve yedekleme. Secret’ın veri deposunda şifrelenmesi, anahtarların döndürülmesi, yedeklerin en az aynı korumaya sahip olması, geri yükleme yetkisinin production yazma yetkisinden ayrılması.

K8S-SEC-04 Canary doğrulaması. S2’de benzersiz, sentetik bir canary secret oluşturun. Yalnızca izin verilmesi beklenen test workload’u okuyabilmeli; başka namespace, başka SA ve düşük yetkili kullanıcı için okuma reddedilmelidir. Kanıtta canary değeri değil, beklenen eşleşmenin gerçekleştiği bilgisi tutulur.

Aşama 7 Ağ güvenliği ve yanal hareket

Politikanın varlığı yeterli değildir; izin matrisini ölçmelisiniz. İki sentetik pod ve sabit yanıt veren bir test servisi kurun.

K8S-NET-01 Dış maruziyet. Dış IP, node portu, load balancer ve ingress yollarını envanterleyin; her dış uç nokta için sahip, veri sınıfı, kimlik doğrulama, TLS ve rate limit durumunu kaydedin. Yönetim panelleri ve metrik uç noktalarını özellikle kontrol edin.

K8S-NET-02 TLS sonlandırma. İstemci→giriş katmanı ve giriş katmanı→backend trafiğini ayrı değerlendirin. Bulgu: yalnızca dış bacakta TLS, hassas backend trafiğinin açık gitmesi.

K8S-NET-03 Varsayılan reddetme. Her uygulama namespace’i için dört durumu ayrı ölçün ve şu matrisi doldurun:

K8S-NET-04 Seçici hataları. Boş pod/namespace selector, yanlış etiket nedeniyle seçilmeyen pod, eklentinin desteklemediği özellik, hostNetwork pod’larının politika dışı kalması, DNS’e fazla geniş izin, IPv4 uygulanırken IPv6’nın unutulması.

K8S-NET-05 Metadata erişimi. Workload’lardan node/altyapı metadata uç noktalarına erişimi yalnızca sentetik bir kimlik ve izin verilmeyen bir istekle ölçün. Gerçek rol kimlik bilgileri alınmaz, kanıta yazılmaz. Beklenen: ağ veya kimlik katmanında ret.

Aşama 8 Node, kubelet ve container runtime

S1’de yapılandırma incelemesiyle başlayın; S3 doğrulamasını yalnızca ayrılmış node üzerinde yapın.

K8S-NODE-01 Kubelet erişimi. Salt okunur ve ana kubelet uç noktalarının ağdan erişilebilirliği, anonymous authentication, webhook auth/authz, istemci sertifikası doğrulaması ve pods/log/exec/stats uç noktalarının yetki davranışı. Beklenen: anonymous kapalı, istekler kimlik doğrulamalı, yetkilendirme webhook üzerinden, ağ erişimi yalnızca gerekli bileşenlerle sınırlı.

K8S-NODE-02 Node proxy ve debug. nodes/proxy, node debug ve ephemeral container yetkileri kimlerde? Bunların secret okumaktan daha yüksek etki yaratabileceğini raporlayın; debug oturumlarının audit’e kullanıcı kimliğiyle yansıdığını doğrulayın.

K8S-NODE-03 Runtime socket ve host mount. Manifestlerde runtime socket, /proc, /sys, /dev, kubelet dizinleri ve host root yoluna mount arayın; gerekli sistem DaemonSet’lerini uygulama iş yüklerinden ayırın. Bulgu: uygulama namespace’inde socket veya geniş host dizini mount’u.

K8S-NODE-04 OS sertleştirmesi. Yama seviyesi, minimum paket/servis, dosya izinleri, kernel güvenlik ayarları, doğrudan yönetim erişimi, disk şifreleme, ayrıcalıklı iş yükleri için özel node havuzu.

K8S-NODE-05 Node kimliği ve sınırı. Node kimliğinin yalnızca kendi pod/node nesnesi için gerekli yetkilere sahip olması, NodeRestriction benzeri sınırların etkin olması, bir node ihlalinin tüm cluster secret’larını listeleme sonucuna dönüşmemesi.

Aşama 9 Image ve yazılım tedarik zinciri

K8S-SC-01 Kaynak ve değişmezlik. Yalnızca onaylı registry, digest pinning, mutable tag engeli, registry kimlik bilgilerinin kapsamı.

K8S-SC-02 Zafiyet yönetimi. Çalışan image envanterini paket/OS bileşenleriyle eşleştirin; internet erişimi olan, privileged çalışan veya hassas secret kullanan iş yüklerindeki açıkları önceliklendirin. Yalnızca CVSS’e değil, erişilebilirlik ve çalışma bağlamına bakın.

K8S-SC-03 Provenance ve imza. Image’in hangi pipeline, kaynak revizyonu ve build kimliğiyle üretildiği izlenebilmeli; imzasız veya beklenmeyen kimlikçe imzalanmış artefaktın admission’da reddedildiği ve yeniden etiketlemeyle politikanın aşılamadığı doğrulanmalı.

K8S-SC-04 Dağıtım kimliği. CI/CD principal’ı cluster-wide yönetici olmamalı; yalnızca hedef namespace ve gerekli kaynak türlerine yazabilmeli; secret okuma ile workload güncelleme yetkileri gereksiz birleşmemeli; insan ve otomasyon kimlikleri ayrılmalı.

Aşama 10 Persistent storage

K8S-STO-01 Erişim sınırı. PVC’lerin doğru namespace/iş yüküyle bağlı olması, aynı volume’un beklenmeyen pod tarafından mount edilememesi, ReadWriteMany kullanımının veri modeline uygunluğu, local/hostPath volume’ların istisna olarak yönetilmesi.

K8S-STO-02 Şifreleme ve snapshot. Disk/snapshot/yedek şifrelemesi, snapshot yetkileri, silinen namespace sonrası veri kalıcılığı, ortamlar arası geri yükleme kontrolü.

K8S-STO-03 StorageClass. Varsayılan StorageClass ayarları, reclaim policy, volume expansion, mount seçenekleri ve topoloji sınırları.

Aşama 11 Gözlemlenebilirlik ve algılama

Önlemeyi test ettiğiniz kadar görebilmeyi de test edin. İzole bir test kimliğiyle olay üretip alarm zincirini ölçün.

K8S-DET-01 Kimlik/RBAC olayları. Başarısız kimlik doğrulama, yasaklanmış secret okuma, yasaklanmış exec, RBAC binding oluşturma denemesi, anonymous kaynak isteği üretilir; her birinin kayda ve alarma dönüşüp dönüşmediği ölçülür.

K8S-DET-02 Riskli workload olayı. Dry-run veya engellenmesi beklenen istekle privileged/hostPath/hostNetwork denenir. Üç sonuç ayrı kaydedilir: (1) API kararı, (2) audit kaydı, (3) güvenlik alarmı ve ulaşma süresi. Yalnızca uyarı üretip nesneyi kabul eden kontrol PARTIAL veya niteliğine göre FAIL sayılır.

K8S-DET-03 Runtime davranışı. S2 test pod’unda zararsız canary davranışları (beklenmeyen child process, hassas olmayan bir yola erişim denemesi, beklenmeyen test adresine bağlantı) kullanılır; algılamanın kullanıcı/pod/namespace/image bağlamıyla görülebildiği kontrol edilir.

K8S-DET-04 Log bütünlüğü. Audit loglarının ayrı güven alanına aktarıldığı, workload kimliğinin logları silemediği, saat senkronizasyonunun korelasyona izin verdiği, hassas değerlerin maskelendiği.

Aşama 12 Dayanıklılık (S4)

Aktif testleri S4 kapsamındadır; üretimde varsayılan olarak yalnızca yapılandırma incelenir.

K8S-RES-01 Kaynak yönetişimi. ResourceQuota, LimitRange, pod CPU/bellek/ephemeral sınırları, pod/nesne sayısı kotaları, PriorityClass/preemption tasarımı.

K8S-RES-02 Dağılım ve kesinti toleransı. Kritik replikaların tek node/zone’da toplanmaması, PodDisruptionBudget, anti-affinity/topology spread, kontrollü node boşaltma davranışı.

K8S-RES-03 Autoscaling kötüye kullanımı. Bir tenant’ın sınırsız pod üreterek node artışına/maliyet saldırısına yol açamaması, HPA metriklerinin manipülasyona kapalı olması, maksimum ölçek ve bütçe sınırlarının tanımlı olması. Aktif yük testinde sentetik workload, katı kota, kısa süre ve otomatik sona erme kullanın; sağlık eşiği aşılırsa test otomatik dursun.

Aşama 13 Çok kiracılı izolasyon

Namespace tek başına güçlü bir güvenlik sınırı sayılmaz. İki sentetik tenant oluşturup şu matrisi doğrulayın:

Yüksek güven gerektiren tenant’lar için ayrı node havuzu, ayrı cluster veya ek izolasyon katmanları gerekebilir.

---

5. Saldırı yolu doğrulama senaryoları

Tekil bulguları test etmeyi öğrendikten sonra, asıl beceri onları zincirlemektir. Amaç “ele geçirme” değil, birden fazla zayıflığın birleşik etkisini minimum müdahaleyle kanıtlamaktır.

Senaryo 1 Düşük yetkili kullanıcıdan workload kimliğine. (1) Düşük yetkili test kullanıcısının pod oluşturabildiği doğrulanır. (2) Daha güçlü bir SA seçip seçemediği dry-run ile ölçülür. (3) Seçebiliyorsa yalnızca canary kaynağa erişen sentetik SA kullanılır. (4) Canary erişimi doğrulandığında durulur. Kök neden: pod oluşturma izni + SA kullanım sınırı + admission birlikte başarısız.

Senaryo 2 Workload oluşturmadan node sınırına. (1) Privileged/host namespace/hostPath içeren her özellik ayrı dry-run ile denenir. (2) Kabul ihtimali görülürse test yalnızca ayrılmış node ve canary host yolunda tekrarlanır. (3) Canary dosyasının varlığı doğrulanır; komut/değişiklik/gerçek dosya okuma yapılmaz. (4) Nesneler hemen silinir. Kök neden: RBAC yalnızca pod oluşturmayı kontrol etmiş, admission ve node izolasyonu etkiyi sınırlamamış.

Senaryo 3 Namespace ihlalinden yanal harekete. (1) Tenant A’daki sentetik pod başlangıçtır. (2) Tenant B’deki sentetik servise ve canary secret’a erişim denenir. (3) API ve ağ sonuçları ayrı kaydedilir. (4) Yalnızca canary değerler kullanılır. Kök neden: RBAC ve NetworkPolicy farklı katmanlardır; birinin başarılı olması diğerindeki boşluğu kapatmaz.

Senaryo 4 Dağıtım zincirinden cluster’a. (1) Dağıtım principal’ının izinli namespace/kaynakları çıkarılır. (2) Onaysız ama zararsız test image’ı dry-run ile sunulur. (3) İmza/provenance ve registry politikalarının reddi beklenir. (4) Workload güncelleme yetkisinin secret/RBAC/system namespace’e uzanmadığı doğrulanır.

Senaryo 5 Görünürde var, gerçekte etkisiz admission. (1) Politika nesnesi ve seçicileri salt okunur incelenir. (2) Tek ihlal içeren manifest dry-run ile gönderilir. (3) Yalnızca warning/audit üretilip istek kabul ediliyorsa kontrol “engelleyici” raporlanmaz. (4) Webhook erişilemezlik senaryosu yalnızca onaylı test ortamında değerlendirilir.

---

6. Bulguları derecelendirme

Şiddeti yalnızca teknik özelliğe göre değil, beş boyutu ayrı puanlayarak verin:

Aynı teknik bulgu bağlama göre farklı derecelenir: privileged pod kabulü dar bir test namespace’inde yüksek, geniş kullanıcı grupları production’da kullanabiliyorsa kritik olabilir. NetworkPolicy yokluğu tek başına orta, hassas servisler kimlik doğrulamasız ve her namespace’ten erişilebiliyorsa etkisi yükselir.

---

7. Geri dönüş ve kapanış

Test bitmez; ortam başladığı hal kadar temiz bırakılınca biter. Geri dönüş sırası: (1) aktif test trafiğini durdurun; (2) test controller/workload’larını silin; (3) test SA/role/binding’leri kaldırın; (4) canary secret/ConfigMap ve geçici volume’ları silin; (5) NetworkPolicy/quota/namespace’i kaldırın; (6) süreli kimlikleri/sertifikaları iptal edin; (7) test etiketi taşıyan artık nesne kalmadığını doğrulayın; (8) cluster sağlığını, pod yeniden başlama sayılarını ve alarm durumunu baz çizgiyle karşılaştırın.

Namespace silme isteğinin kabul edilmesi geri dönüşün tamamlandığı anlamına gelmez. Finalizer nedeniyle kalan kaynaklar, dış load balancer’lar, persistent volume’lar, snapshot’lar ve dış kimlik bağları ayrıca kontrol edilmelidir.

Kapanış ölçütleri: her test bir durumla kaydedildi; her FAIL için tekrar üretilebilir fakat güvenli kanıt var; her BLOCKED’ın nedeni yazıldı; test kaynaklarının kalmadığı iki bağımsız yöntemle doğrulandı; hassas kanıtlar maskelendi; bulgulara sahip ve hedef tarih atandı; kritik bulgular için kısa vadeli telafi tanımlandı; yeniden test ölçütleri ölçülebilir yazıldı.

---

Son söz

İyi bir Kubernetes pentestinin değeri, ne kadar çok komut çalıştırdığında değil; güven sınırlarını ne kadar doğru modellediğinde, kontrollerin gerçek davranışını ne kadar güvenli kanıtladığında ve ortamı başladığı hal kadar temiz bırakabildiğinde ortaya çıkar.

En yararlı rapor, uzun bir yanlış yapılandırma listesi değildir. Düşük yetkili bir başlangıç noktasından hangi koşullarda namespace, node veya cluster etkisine ulaşılabildiğini ve bu zincirin en doğru nerede kırılacağını gösteren rapordur. Çünkü sonuçta test ettiğimiz şey, kontrolün varlığı değil; kararıdır.

---

---

Bu playbook, Red in Pulse ekibinin Kubernetes sızma testi çalışmalarında izlediği yaklaşımın çerçevesidir: güven sınırlarını doğru modelleyen, kontrolleri gerçek saldırı yollarıyla ve güvenli doğrulama disipliniyle sınayan, ortamı başladığı hal kadar temiz bırakan bir metodoloji. Cluster’ınızın kararlarını sadece kontrollerinin varlığını değil bu titizlikte test ettirmek isterseniz, kapsam görüşmesi için bizimle iletişime geçebilirsiniz.