Kubeflow Üzerinde Hesap Ele Geçirme ve İç Ağ Saldırıları

Genel Bakış

Kubeflow genellikle yüksek yetkili makine öğrenmesi defterleri (notebooks) çalıştırır. Zafiyet barındıran ML platformları kimlik doğrulama atlatmaları ile saldırganlara Kubernetes kümesinin tamamına erişim verebilir.

Çözüm Önerileri

Istio entegrasyonlarını güçlendirin ve Node IAM rollerini NetworkPolicy ile engelleyin.

Temel Değerlendirme

MLOps güvenliği; notebook, pipeline, model registry, inference API, storage ve Kubernetes katmanlarının tek zincir olarak test edilmesidir. Bir zafiyet çoğu zaman sadece modelde değil, modeli yükleyen servis, artefact izni veya cluster içi ağ erişiminde ortaya çıkar.

Bu Konu Neden Önemli?

MLOps araçları çoğu zaman dosya sistemi, model artefact ve iç ağ erişimine geniş yetkilerle çalışır.
Web/API güvenlik hataları ML pipeline içinde veri, model ve credential sızıntısına dönüşebilir.
Model registry ve job runner bileşenleri, kurum içi ağda yüksek güvenli kabul edildiği için yeterince test edilmez.

Güvenlik ekipleri açısından değer, tekil bir bulgunun adından çok bulgunun hangi veriye, kullanıcıya, sisteme veya iş sürecine temas ettiğini gösterebilmekten gelir.

Bu nedenle değerlendirme yapılırken sadece teknik kontrol listesi değil, gerçek saldırı yolu, istismar kanıtı, operasyonel etki ve düzeltme önceliği birlikte ele alınmalıdır.

Pratik Örnek

Bir Kubeflow veya benzeri platformda düşük yetkili kullanıcı, yanlış yapılandırılmış notebook veya pipeline üzerinden cluster içi servislere ulaşabiliyorsa sorun sadece arayüz bug’ı değildir. Bu durum service account, namespace izolasyonu, artefact izinleri ve metadata erişimiyle birlikte ele alınmalıdır.

Yanlış Bilinenler

MLOps aracını sadece veri bilimi aracı gibi görmek.
Local veya internal çalışan servislerde authentication gereksiz sanmak.
Model upload ve import akışlarını standart dosya yükleme testiyle sınırlamak.

Karar Tablosu

| Durum | Risk | Ne Yapılmalı? | | --- | --- | --- | | Sistem hassas veriye erişiyor | Veri sızıntısı veya yetki aşımı | Kapsamlı güvenlik testi planlanmalı | | Sadece demo ortamında çalışıyor | Düşük ama büyüyebilir risk | Mimari ve veri akışı şimdiden belgelenmeli | | Üretime yakın entegrasyon var | Zincirleme etki ve operasyon riski | Assessment, remediation ve retest takvimi çıkarılmalı |

Uygulanabilir Kontrol Listesi

Varlık, veri ve kullanıcı rolleri açıkça listelendi mi?
Kritik akışlar gerçek kullanıcı senaryolarıyla test edildi mi?
Yetki sınırları hem başarılı hem başarısız isteklerle doğrulandı mı?
Log, hata mesajı ve izleme sistemleri hassas veri sızdırıyor mu?
Bulgu çıktıları iş etkisi ve remediation sahibiyle birlikte yazıldı mı?
Düzeltme sonrası retest kriteri önceden belirlendi mi?

Profesyonel Destek Ne Zaman Gerekir?

MLOps platformu çok kullanıcılı çalışıyorsa, model yükleme alıyorsa veya Kubernetes üzerinde production verisine yakın koşuyorsa profesyonel assessment gerekir.

Profesyonel destek gerektiren en net sinyal, riskin tek bir ekip tarafından tamamen görülememesidir. Ürün, güvenlik, DevOps, veri ve hukuk ekipleri aynı soruya farklı cevap veriyorsa bağımsız assessment işi hızlandırır.

Eresus Yaklaşımı

Eresus Security bu tip konularda yalnızca bulgu listesi üretmez; saldırı yolunu, iş etkisini, kanıtı, önerilen düzeltmeyi ve retest koşulunu birlikte verir.

Çalışma çıktısı teknik ekip için uygulanabilir, yönetim için anlaşılır ve satış/uyum görüşmeleri için kanıt niteliği taşıyacak şekilde hazırlanır.

Eresus Security, MLOps ve AI pipeline güvenliğini web/API pentest tecrübesiyle model artefact risklerini birleştirerek inceler. Kapsamı birlikte çıkarıp en kritik inference, registry ve pipeline yollarını test edebiliriz.

Saha Kontrol Soruları

Notebook servisleri kimlik doğrulama istiyor mu?
Namespace izolasyonu tenant sınırını koruyor mu?
Model registry yazma izni kimlerde?
Artefact download path traversal’a açık mı?
Pipeline job runner hangi service account ile çalışıyor?
Metadata servisine erişim kısıtlı mı?
Upload edilen model karantinaya alınıyor mu?
Inference API rate limit içeriyor mu?
İç ağ erişimi gereksiz açık mı?
Cluster logları credential sızdırıyor mu?
Job çıktıları hassas veri içeriyor mu?
Kullanıcı rolleri deney ve deployment için ayrılmış mı?
Model silme ve geri alma izleniyor mu?
S3 veya blob izinleri minimum yetkide mi?
Debug endpoint’leri kapalı mı?

Sık Sorulan Sorular

Kubeflow Üzerinde Hesap Ele Geçirme ve İç Ağ Saldırıları için ilk bakılması gereken şey nedir?

İlk bakılması gereken şey sistemin hangi veriye, hangi kimlikle ve hangi aksiyon yetkisiyle eriştiğidir. Teknik araç seçimi bundan sonra anlam kazanır.

Bu çalışma yalnızca otomatik araçlarla yapılabilir mi?

Otomatik araçlar iyi bir başlangıçtır ama iş mantığı, yetki sınırı, zincirleme etki ve gerçek istismar kanıtı için manuel güvenlik analizi gerekir.

Çıktı nasıl aksiyona dönüşür?

Her bulgu için etki, kanıt, önerilen düzeltme, sorumlu ekip ve retest kriteri yazılır. Böylece rapor sadece okunmaz, sprint veya güvenlik backlog’una girer.

Eresus bu konuda nasıl destek verir?

Eresus Security kapsam çıkarma, teknik test, risk önceliklendirme, remediation danışmanlığı ve retest aşamalarını tek bir çalışma akışıyla destekler.

Uygulama Planı

1. Kapsamı Netleştir

Notebook, registry, storage, job runner, inference API ve cluster servisleri tek akış olarak çıkarılır.
Kullanıcı rolleri deney, model yayınlama ve artefact erişimi seviyesinde ayrıştırılır.
Kubernetes, service account ve internal network sınırları test kapsamına eklenir.

2. Kanıt Üret

Bir web/API hatasının model, veri veya credential erişimine dönüşüp dönüşmediği gösterilir.
Artefact indirme ve yükleme akışlarında dosya sistemi ve path kontrolü doğrulanır.
Pipeline job çıktıları, metadata erişimi ve loglar kanıt olarak korunur.

3. Düzeltmeyi Takip Edilebilir Hale Getir

Namespace izolasyonu, registry izinleri ve service account scope’ları daraltılır.
Model intake karantina ve provenance kontrolleriyle ayrılır.
Internal-only servislerde de authentication ve audit zorunlu hale getirilir.

Raporlama Formatı

Bulgu adı kısa ve teknik olarak net yazılmalı.
Etkilenen varlık, kullanıcı rolü ve veri sınıfı belirtilmeli.
İstismar adımları tekrar üretilebilir ama gereksiz saldırı detayı içermeyecek şekilde verilmeli.
İş etkisi, teknik etkiden ayrı açıklanmalı.
Önerilen düzeltme, sorumlu ekip ve retest kriteri aynı blokta yer almalı.

İç Link ve Sonraki Okuma Stratejisi

Yazı ilgili hub sayfasına bağlanmalı.
Aynı pillar içindeki iki destekleyici bloga bağlantı verilmelidir.
Hizmet sayfasına giden CTA, okuyucunun bulunduğu karar aşamasına uygun olmalıdır.
Advisory veya araştırma içeriği varsa güven sinyali olarak ikincil bağlantı şeklinde kullanılmalıdır.

Sonraki Adım

Bu yazıdan sonra MLOps bug hunting, Kubernetes black-box pentest ve AI model dosyası güvenliği içerikleri aynı cluster içinde değerlendirilmelidir.