Kubernetes (K8s) Sızma Testi Rehberi: Black Box Yaklaşımı

Uygulamalarımızı konteynerleştirip mikroservislerle yönettikçe Kubernetes (K8s) her modern IT ekibinin vazgeçilmez altyapısı haline geldi. Ancak koca bir bulut (Cloud) ekosistemini orkestre eden bu devasa yapı, yapılandırma eksikliklerinde siber korsanlar (hacker'lar) için "cennetin kapısı" konumundadır.

Temel Değerlendirme: Bir Kubernetes kümesinin Black Box (Kara Kutu) sızma testi, saldırganın sistem hakkında hiçbir içeriden bilgisi olmadan -sadece dışa bakan servislere, API uçlarına veya pod içine yerleştirdiği masum görünen bir komut ile- kümeyi (Cluster) ele geçirmesini hedefler. Sızma testi esnasında en çok, internete açık unutulan Kube-apiserver portları, kimlik doğrulaması kapatılmış (Anonymous Access) Kubelet yapılandırmaları ve yetki kontrolü zayıf (RBAC misconfiguration) profiller suistimal edilir.

Bu makalede Eresus Security tarzı ileri düzey Cloud Pentest operasyonlarında bir K8s kümesinin nasıl adım adım haritalandırılıp, istismar (expoloit) edildiğinin Playbook (oyun planı) anatomisini sunuyoruz.

1. Dış Keşif (External Recon)

Saldırganlar işe dışarıdan açık olan noktaları (Attack Surface) tarayarak başlar.

Kubernetes API Sunucusu (6443 / 443 TCP): Varsayılan ayarlarda API Server sadece yetkili sertifikalarla erişime açılmalıdır. Ancak yanlış yapılandırılmış bir API, anonim kullanıcıların https://api.domain.com/version hatta daha tehlikelisi api/v1/pods komutlarını okumasına izin verebilir.
Kubelet Portları (10250 TCP): Her bir Node (sunucu) üzerinde çalışan Kubelet, yetkilendirmesi (authentication) açık unutulduğunda facianın ta kendisidir. Saldırgan dışarıdan 10250 portuna bir curl atarak sistemde doğrudan "exec" komutları (bash) çalıştırabilir.

2. Pod İçinden Küme Ele Geçirme (Lateral Movement & Escalation)

Diyelim ki saldırgan dışarıda açık bulduğu bir web uygulamasındaki minik bir zafiyetle (SSRF ya da RCE) bir K8s Pod'unun içerisine düştü. Artık iç ağdadır. Black Box testi İç Keşif (Internal Recon) aşamasına geçer.

A. Hizmet Hesabı Jetonları (Service Account Tokens)

K8s'de varsayılan olarak her pod içerisine bir "Service Account Token" otomatik olarak bağlanır (mount edilir). Saldırgan pod içerisindeyken şu dizine gider: /var/run/secrets/kubernetes.io/serviceaccount/token Eğer bu jetonun (token), Küme Yöneticisi (ClusterRole) veya sırları (Secrets) okuyabilme rolü varsa, saldırgan tek bir curl komutu ile sistemdeki tüm veritabanı şifrelerini çalabilir veya kendine yeni yönetici podları (Privileged Pod) oluşturabilir.

B. Bulut Metadata Servislerine Sıçrama (Cloud Metadata SSRF)

AWS (EKS), Azure (AKS) veya GCP (GKE) gibi yönetilen bulut servislerinde pod'lar bulutun kendi meta-veri servislerine (169.254.169.254) erişebiliyor olabilir. Pod'un içine yerleşen korsan, bu adresi sorgulayarak AWS IAM rollerine sahip geçici JWT oturumlarını çalabilir. Bu da Kubernetes sınırlarını aşıp doğrudan şirketin Bulut Altyapısını ele geçirmek demektir.

3. Kubernetes Neden Standart Pentestler İle Kontrol Edilemez?

Standart bir otomasyon ağ tarayıcısı (Nesus, OpenVAS vs.) sunuculara sadece dışarıdan IP bazlı bakar, güncel olmayan Apache varsa söyler. Fakat o sunucuların Kubernetes üstünde "mantıksal" olarak uçtan uca ağ ile birbirine bağlı olduğundan (CNI - Flannel/Calico vb.), Pod'dan Kaçış (Pod Escape) zafiyetinden habersizdir.

Çalışan Pod'ların Security Context değerlerinin yanlış verilip (örneğin privileged: true) Linux Kernel izolasyonunun bozulması.
RBAC (Rol Tabanlı Erişim Kontrolü) izinlerinin geliştiricilere aşırı geniş (Wildcard *) dağıtılması.

Bu denli sofistike hataları görebilmek için sistemin "Konteyner ve Bulut Yerel" (Cloud-Native) güvenliği dinamiklerini çok iyi bilen ofansif siber güvenlik mühendislerinin Black Box Kubernetes simülasyonları yapması zorunludur.

"Bir pod kaybederseniz uygulamanız çökebilir; cluster yetkinizi (Token) kaybederseniz tüm şirketinizin dijital omurgasını kaybedersiniz."

Siz de şirketinizin bulut mimarisinde ve mikroservis iletişimlerinde güvenlik boşlukları olabileceğinden şüpheleniyorsanız, Eresus Security'nin ileri düzey Bulut ve K8s Sızma Testi operasyonları için uzmanlarımızla hemen görüşebilirsiniz.

Saha Kontrol Notları

DevSecOps güvenliği, pipeline’a araç eklemekten daha fazlasıdır. Asıl hedef, riskli değişikliğin production’a taşınmadan görünür ve durdurulabilir hale gelmesidir.

İnceleme sırasında şu kanıtlar toplanmalıdır:

CI/CD token’ları hangi kaynaklara erişiyor?
Secret bulunduğunda otomatik revoke veya rotate akışı var mı?
Branch protection ve environment approval açık mı?
Build artefact’ları imzalanıyor mu?
Container image kaynakları doğrulanıyor mu?
Dependency güncellemeleri güven politikasıyla yönetiliyor mu?
Pipeline loglarında hassas veri tutuluyor mu?
Deploy kimliği kişisel hesaplardan ayrılmış mı?
Incident halinde hangi secret’ın kullanıldığı görülebiliyor mu?
Retest için pipeline kanıtı üretilebiliyor mu?

Uygulama Kontrol Listesi

Uzun ömürlü token’lar azaltılmalı.
Secret scanning rotasyon akışıyla bağlanmalı.
İmzasız artefact production’a alınmamalı.
Kritik branch’lerde review ve status check zorunlu olmalı.
Pipeline yetkileri ortam bazında ayrılmalı.
Olay müdahalesi kod temizliğiyle sınırlı bırakılmamalı.

Karar Noktası

Secret veya CI/CD token production erişimi sağlayabiliyorsa olay acildir. Eresus Security pipeline, token ve artefact zincirini birlikte inceleyerek gerçek etki alanını çıkarır.

Operasyonel İnceleme Checklisti

Secret bulunduğunda revoke ve rotate akışı var mı?
CI/CD token kapsamı minimum yetkide mi?
Branch protection zorunlu mu?
Environment approval kritik deploylarda açık mı?
Artefact imzası doğrulanıyor mu?
Pipeline logları secret sızdırıyor mu?
Dependency güveni build aşamasında kontrol ediliyor mu?
Container registry erişimi sınırlı mı?
Git history temizliği olay müdahaleden ayrıldı mı?
Token kullanım kanıtı loglardan çıkarılabiliyor mu?
Kapsam net yazıldı mı?
Etkilenen varlık sahibi belli mi?
Test ortamı production etkisinden ayrıldı mı?
Kullanıcı rolleri doğru temsil ediliyor mu?
Hassas veri sınıfı tanımlandı mı?
Yetki sınırı teknik olarak doğrulandı mı?
Log kaynağı ve saklama süresi belli mi?
Bulgu tekrar üretilebilir kanıtla destekleniyor mu?
İş etkisi teknik etkiden ayrı açıklandı mı?
Düzeltme sahibi belirlendi mi?
Retest kriteri yazıldı mı?
Benzer risklerin nerelerde tekrar edebileceği kontrol edildi mi?
Monitoring veya alert tarafında görünürlük var mı?
Olay müdahale adımı gerekiyorsa planlandı mı?
Yönetim özeti teknik jargona boğulmadan hazırlanabilir mi?

Sonraki Teknik Adım

Bu checklist tamamlandıktan sonra bulgular önem sırasına göre backlog’a taşınmalı, kritik riskler için retest planı çıkarılmalı ve ilgili servis/hub sayfasına iç bağlantı verilmelidir. Eresus Security bu aşamada kapsam netleştirme, kanıt üretme ve remediation önceliklendirme konusunda teknik ekiplerle birlikte çalışır.

Ek Kontrol Soruları

Bu risk hangi varlıkları etkiliyor?
Hangi kullanıcı rolleri bu akışa erişebiliyor?
Aynı sorun başka endpoint veya entegrasyonda tekrar ediyor mu?
Bulgunun müşteri verisine etkisi var mı?
Loglardan olayın izi sürülebiliyor mu?
Düzeltme sonrası retest nasıl yapılacak?
Geçici önlem ile kalıcı çözüm ayrıldı mı?
İş etkisi teknik ekibin dışında da anlaşılır mı?
Benzer hata için önleyici kontrol eklenebilir mi?
Ekip bu kontrolü release sürecine bağlayabilir mi?
Gerekirse bağımsız doğrulama için hangi kanıtlar hazırlanmalı?
Sonraki sprintte hangi iç bağlantı ve servis sayfası desteklemeli?