Kubernetes Ortamlarında Adli Bilişim: Dağıtık ve Dinamik Sistemlerde Delil Toplama

Kubernetes (K8s), container tabanlı uygulamaları otomatik, ölçeklenebilir ve dağıtık şekilde yöneten bir orkestrasyon platformudur. Ancak bu dinamizm, adli bilişim açısından ciddi zorluklar doğurur. Pod’lar saniyeler içinde oluşup yok olabilir, IP’ler değişir, log’lar merkezi değildir. Bu makalede Kubernetes ortamlarında nerede iz bırakıldığını, hangi delillerin toplanabileceğini ve olayların nasıl rekonstrükte edileceğini ele alıyoruz.

Kubernetes Forensics Nedir?

Kubernetes adli bilişimi; cluster, node, control plane ve workload seviyelerinde oluşan log, metadata, konfigürasyon ve davranış izlerinin toplanması ve analizidir.

Kapsadığı başlıca alanlar:

- Control Plane (API Server, etcd)
- Worker Node’lar
- Pod / Container yaşam döngüsü
- Network (CNI) ve servisler
- RBAC ve IAM yetkileri

Kubernetes Mimarisi: Nerelerde Delil Var?
Kritik Bileşenler

- API Server → Tüm işlemlerin kapısı
- etcd → Cluster’ın beyni (state & config)
- Scheduler → Pod yerleşim kararları
- Controller Manager → Otomasyon izleri
- Worker Node → Gerçek çalışma alanı

Adli Bilişim Açısından Neden Önemli?
1. İç Tehdit ve Yetki Suistimali

- Kim kubectl delete çalıştırdı?
- Kim gizli bir pod deploy etti?
- RBAC yanlış mı kullanıldı?

2. Cloud & Container Saldırıları

- Kripto madenciliği (cryptomining pod’ları)
- Backdoor container’lar
- Yetkisiz image pull

Kubernetes’te Başlıca Delil Kaynakları
1. Audit Logları (Altın Değerinde)

Audit logları:

- Kim?
- Ne yaptı?
- Ne zaman?
- Hangi kaynaktan?

sorularının cevabını verir.

2. etcd (Cluster State)

etcd içinde:

- Deploy edilen pod’lar
- Secrets
- ConfigMap’ler
- RBAC kuralları

bulunur.

3. Pod ve Container Artefact’leri

- Pod YAML tanımları
- Environment variable’lar
- Image hash’leri
- Restart sayıları

1kubectl describe pod suspicious-pod

4. Node (Worker) Seviyesi İzler

- Container runtime (containerd/docker) logları
- /var/log/ altındaki kubelet kayıtları
- OverlayFS kalıntıları

Adli Analize Nereden Başlanmalı?
1. Olay Kapsamını Belirle

- Tek pod mu?
- Namespace mi?
- Tüm cluster mı?

1kubectl get namespaces

2. Şüpheli Workload’ları Tespit Et

1kubectl get pods -A -o wide

Dikkat edilmesi gerekenler:

- Bilinmeyen image’lar
- Şüpheli registry’ler
- Beklenmeyen çalıştırma süreleri

3. Pod Tanımı ve Davranışı

1kubectl get pod suspicious-pod -o yaml

Şüpheli göstergeler:

- privileged: true
- HostPath mount’ları
- hostNetwork: true

Adli Senaryo Örneği

Olay:
Cluster’da ani CPU artışı tespit ediliyor.

Analiz:

- Yeni namespace oluşturulmuş
- İçinde “normal” isimli pod’lar
- Image: bilinmeyen registry
- Audit log → kubectl apply dış IP’den

Sonuç:

- Kripto madenciliği pod’ları
- Yetkisiz erişim + RBAC zafiyeti
- Kötü niyetli deploy kanıtlandı

Kubernetes ve Anti-Forensics
Yaygın Taktikler

- Pod’ları hızla silme
- Ephemeral container kullanımı
- Log’ları stdout’ta bırakma
- Namespace’i komple silme

Adli Analistler İçin Pratik İpuçları
Audit Logları Önceliklendir

- Yoksa, olay rekonstrüksiyonu zorlaşır

RBAC Kurallarını İncele

- Aşırı yetki = potansiyel saldırı yüzeyi

Image Kaynağını Doğrula

- Resmi registry mi?
- Hash değişmiş mi?

Zaman Çizelgesini Cluster Bazında Kur

- Pod zamanı ≠ node zamanı ≠ cloud zamanı

Hukuki ve Adli Değer

Mahkemelerde:

- Audit log bütünlüğü
- API çağrılarının kaynağı
- Read-only analiz yöntemi

özellikle vurgulanmalıdır.

#AdliBilişim #kaynak