Kubernetes üzerindeki multi-tenant mimarilerinin güvenlik riskleri nelerdir?

09 Ağu 22:58

Kubernetes’te multi‑tenant çalıştırmak, özellikle “namespace” üzerinden izole etme fikri çok çekici, ama bu izolasyonun sınırlarını iyi kavramak lazım. Namespace sadece bir ad alanıdır, kaynak seviyesinde bir sınır koymaz; bu yüzden **RBAC** yapılandırması eksik kalırsa bir takımın service account’u diğer takıma ait secret’lara ya da cluster‑wide rol‑binding’lere ulaşabilir. Valla bu tip bir privilege escalation, özellikle “cluster‑admin” gibi geniş yetkili rollerin yanlışlıkla bir namespace’e bağlanmasıyla büyük bir güvenlik açığı yaratıyor. Ayrıca **NetworkPolicy**’lerin eksik ya da “default allow” olması, pod’lar arasında yan yana çalışırken yan kanal saldırılarına (side‑channel) ve veri sızdırmalarına zemin hazırlıyor. Bir diğer risk, kaynak tüketiminde **quota** eksikliğiyle gelen DoS (Denial‑of‑Service) senaryoları. Bir takım, örneğin “burstable” QoS sınıfındaki pod’larıyla CPU ve memory’yi doldurup diğer takımların iş yükünü baltalıyor. Bunun yanı sıra **etcd** şifreleme ve erişim kontrolleri yetersizse, tüm cluster konfigürasyonu ve secret’lar tek bir noktada tehlikeye giriyor. Image‑level güvenlik de kaçınılmaz; kötü imajlar ya da güncel olmayan paketler, pod’da çalışan bir uygulamayı kolayca kompromize edebiliyor. Riskleri minimize etmek için en iyi uygulamalara kısaca bakacak olursak: 1. **RBAC**’yi “deny‑all” mantığıyla başlatıp, sadece kesinlikle gerekli izinleri “least‑privilege” olarak ekleyin. Service account’ları namespace‑sadece sınırlandırmalı ve **OPA/Gatekeeper** gibi policy engine’lerle otomatik denetimler koyun. 2. **NetworkPolicy**’yi varsayılan olarak “drop‑all” yapın, ardından sadece belirli pod‑setler arasında izin verilen trafiği whitelist edin. Bu, yan kanal ve veri sızdırma riskini büyük ölçüde azaltır. 3. **PodSecurity Standards** (veya eski PSP) ile “restricted” seviyesini zorunlu kılın, root‑less container, read‑only filesystem ve seccomp profilini etkinleştirin. 4. **Node‑pool izolasyonu** (taint/toleration) ve **taint‑based tenancy** ile takımlara ayrı node grupları atayın; kritik iş yükleri için fiziksel ayrı ayrı cluster (hyper‑scale) de düşünülebilir. 5. **ResourceQuota** ve **LimitRange** ile CPU/memory sınırlarını kontrol altında tutun, burstable kaynakları sınırlı tutarak DoS saldırılarını önleyin. 6. **etcd**‑yi TLS ve at‑rest encryption ile koruyun, erişim denetimlerini sıkı tutun. 7. **CI/CD pipeline**’da imaj taraması (Trivy, Clair) ve runtime güvenlik (Falco, kube‑audit) entegrasyonu ekleyin; bir şeyler ters gittiğinde anında alarm alın. Bence bu adımları bir bütün olarak uyguladığınızda, multi‑tenant ortamınızın “izole” değil “güvenli” olduğunu söyleyebiliriz. Kanka, unutmayın; güvenlik bir kere kurulup bırakılan bir şey değil, sürekli izleme ve politika güncellemeleri gerektiren bir süreç. Eğer spesifik bir senaryoda takıldıysanız, logları ve audit raporlarını paylaşın, beraber bakarız.