Namespace bir güvenlik sınırı değildir: çok kiracılı Kubernetes’te dört duvar
ReadyOn’s Four Walls of tenant isolation on Amazon EKS · Roshan Daneshvaran
ReadyOn, Fortune 100 şirketlerine iş gücü yönetimi sunan, bordro verisi, organizasyon hiyerarşisi ve operasyonel analitik gibi çok hassas veri işleyen bir platformu Amazon EKS üzerinde çok kiracılı olarak işletiyor. Yazının çıkış noktası şu tespit: varsayılan bir Kubernetes kurulumu kutudan güvenli çıkmaz (anonim isteklerin API sunucusuna ulaşabilmesi, pod’ların varsayılan olarak root çalışması, ağ politikalarının sen yazana kadar olmaması).
Çok kiracılılık tehdit modelini değiştiriyor: soru artık ‘yetkisiz biri kümeye ulaşabilir mi?’ değil, ‘Kiracı A, Kiracı B’nin verisine erişebilir mi?’ Çoğu platform tek bir yalıtım mekanizmasına, namespace’e dayanıyor; oysa Kubernetes tasarımcıları namespace’leri hiçbir zaman bir güvenlik sınırı olarak düşünmedi.
ReadyOn’ın Dört Duvar modeli bağımsız dört katmanı birleştiriyor. Duvar 1, namespace: kiracı başına namespace, sıkı RBAC, kaynak kotaları ve admission kontrolü; hepsi bir Argo CD ApplicationSet’iyle üretiliyor, her kiracı özdeş yapılandırma alıyor. Duvar 2, hesaplama: Karpenter, kiracı başına ayrı otomatik ölçeklenen düğüm havuzları açıyor ve çift taint stratejisi kullanıyor: her düğüm hem kiracıyı hem iş yükü tipini belirten taint taşıyor, pod’un ikisini de tolere etmesi gerekiyor. Duvar 3, ağ: kiracı başına VPC güvenlik grupları veritabanı erişimini yalnızca o kiracının düğüm havuzuna kısıtlıyor; Kubernetes ağ politikaları namespace’ler arası varsayılan reddi uyguluyor; küme API sunucusu özel. Duvar 4, veri: kiracı başına ayrı Aurora kümesi ve kiracıya özgü Secrets Manager sırları; iş yükleri IRSA ile kısa ömürlü kimlik bilgisi kullanıyor.
Mantık bileşik savunma: sınırı aşmak için yetkisiz bir kullanıcının Kubernetes API’sini, düğüm zamanlayıcısını, AWS’in yazılım tanımlı ağını ve veri katmanını aynı anda aşması gerekiyor.
Öne çıkanlar
- Namespace mantıksal bir gruplamadır; kernel, düğüm ve ağ düzeyinde yalıtım sağlamaz.
- Her duvar farklı bir teknik gerektirdiği için tek bir açık tüm yalıtımı bozmaz (derinlemesine savunma).
- Kiracı kaynaklarının tamamı şablondan (ApplicationSet) üretiliyor: elle yapılandırma sapmaya yol açar.
- En güçlü yalıtım veri katmanında: kiracı başına ayrı veritabanı, ayrı sır, kısa ömürlü kimlik bilgisi.
- Maliyet bu güvenliğin fiyatı: yalıtım derecesi arttıkça kaynak paylaşımı ve verimlilik azalır.
Neden önemli?
Çok kiracılı sistemde gerçek risk dışarıdan saldırgan değil, bir kiracının bir hata ya da açık yüzünden başkasının verisini görmesidir. Yalıtım düzeyi, ne kadar hassas veri taşıdığına göre seçilen bir mimari karardır: ucuz ve paylaşımlı ile pahalı ve yalıtık arasında bir skala var.
Sende karşılığı
Mobit’teki ERP uygulaması şirket bazlı doküman düzenlemesi yapıyor, yani sen de çok kiracılısın. En önemli soru: kiracı yalıtımını uygulama kodunda (WHERE company_id = ?) mı sağlıyorsun? O tek duvardır ve bir sorguda unutulan filtre başka şirketin verisini sızdırır. PostgreSQL’in Row Level Security özelliği ikinci bir duvar ekler: kural veritabanında durur ve unutulan bir filtreyi bile yakalar. Her kiracıya ayrı veritabanı vermek en güçlüsü ama pahalı; RLS çoğu proje için en iyi denge.
Sözlük
- multi-tenancy çok kiracılılık
- Aynı altyapıyı birbirinden bağımsız birden fazla müşterinin (kiracı) paylaşması.
- taint / toleration leke / tolerans
- Kubernetes’te belirli düğümlere yalnızca ilgili tolerasyonu taşıyan pod’ların yerleşmesini sağlayan mekanizma.
- RBAC rol tabanlı erişim denetimi
- İzinlerin kullanıcıya değil role bağlanıp rollerin kullanıcılara atandığı yetkilendirme modeli.
- row level security (RLS) satır düzeyi güvenlik
- Veritabanında hangi kullanıcının hangi satırları görebileceğini tanımlayan, sorgudan bağımsız kurallar.
- IRSA servis hesapları için IAM rolleri
- Kubernetes pod’larına, uzun ömürlü anahtar olmadan kısa ömürlü AWS yetkisi veren mekanizma.