Konteyner ve Kubernetes Güvenliği: Docker, K8s ve En İyi Uygulamalar

Hızlı Cevap: Konteynerler ve Kubernetes, modern uygulamaları hızlı ve ölçeklenebilir biçimde çalıştırmanın standart yolu haline geldi, ama bu hız çoğu zaman güvenliğin gözden kaçmasına yol açıyor. Konteyner güvenliği dört katmanda ele alınır. Birincisi imaj güvenliği, konteyner imajlarının bilinen zafiyetlere karşı taranması ve yalnızca güvenilir kaynaklardan alınması. İkincisi çalışma zamanı güvenliği, bir konteynerin kök (root) yetkisiyle çalıştırılmaması, gereksiz yeteneklerin kısıtlanması ve konteynerin ana makineden izole tutulması. Üçüncüsü Kubernetes küme güvenliği, API sunucusuna erişimin sıkı kimlik doğrulamayla sınırlanması, ağ politikalarıyla pod'lar arası trafiğin kısıtlanması ve rol tabanlı erişim kontrolünün (RBAC) doğru yapılandırılması. Dördüncüsü sırların yönetimi, veritabanı parolaları ve API anahtarlarının konteyner imajına ya da ortam değişkenine gömülü bırakılmaması, bir sır yönetim aracıyla korunması. Bu dört katman birlikte uygulanmadan, bir konteyner ortamı hızlı ama savunmasız kalır.

Konteynerler, bir uygulamayı ve onun tüm bağımlılıklarını tek bir taşınabilir birimde paketler, Kubernetes ise bu birimleri büyük ölçekte otomatik olarak dağıtır ve yönetir. Bu mimari, geliştirme hızını inanılmaz artırdı, ama aynı zamanda geleneksel güvenlik modellerinin göz ardı ettiği yeni bir saldırı yüzeyi yarattı. Kaynak kodun ve yazılım tedarik zincirinin genel güvenliğini kaynak kodu güvenlik denetimi, SAST, DAST, SCA ve tedarik zinciri saldırıları yazılarımızda anlattık. Bu yazı, konteyner ve Kubernetes'e özgü güvenlik risklerini ve savunmayı ele alır.

Neden konteynerler farklı bir güvenlik yaklaşımı ister

Geleneksel bir sunucuda, güvenlik nispeten durağan bir hedefi korumaktır. Konteyner dünyasında ise ortam sürekli değişir, yüzlerce konteyner saniyeler içinde oluşturulur ve yok edilir, imajlar sık güncellenir ve bir uygulama onlarca mikroservise bölünür. Bu dinamizm, güvenliği bir kerelik bir kontrol değil, sürekli ve otomatikleştirilmiş bir süreç haline getirir.

Ayrıca konteynerler, ana makinenin çekirdeğini paylaşır, sanal makinelerden farklı olarak tam izolasyon sağlamaz. Bu, bir konteynerden ana makineye ya da diğer konteynerlere sıçrama riskini gündeme getirir. Bu risk, konteyner güvenliğini yalnızca uygulama güvenliğinin bir uzantısı değil, kendi başına bir disiplin yapar.

İmaj güvenliği, temelden başlamak

Bir konteynerin güvenliği, temel aldığı imajla başlar. Güvensiz ya da güncel olmayan bir temel imaj, üzerine ne kadar güvenlik eklerseniz ekleyin, zayıf bir zemin oluşturur.

  • Zafiyet taraması. Her imaj, dağıtılmadan önce bilinen zafiyetlere karşı otomatik taranmalıdır. Bunu derleme hattına (CI/CD) eklemek, riskli bir imajın üretime sızmasını engeller.
  • Minimal imaj kullanımı. Bir imajda ne kadar az bileşen varsa, saldırı yüzeyi o kadar küçüktür. Gereksiz araç ve kütüphane içeren büyük imajlar yerine, yalnızca gerekli olanı içeren minimal imajlar tercih edilmelidir.
  • Güvenilir kaynak. İmajlar yalnızca doğrulanmış ve güvenilir kayıt defterlerinden (registry) alınmalı, imzası ve kaynağı doğrulanmalıdır. Bu, tedarik zinciri saldırılarına karşı temel bir savunmadır.
  • Düzenli güncelleme. Bir imaj bir kez güvenli olsa bile, zamanla yeni zafiyetler ortaya çıkar. İmajlar düzenli olarak yeniden taranmalı ve güncellenmelidir.

Çalışma zamanı güvenliği, konteyner çalışırken

Bir konteyner çalışmaya başladığında, birkaç temel kural saldırı yüzeyini daraltır.

  • Kök olmayan kullanıcı. Bir konteyner, mümkün olduğunda kök (root) yetkisiyle değil, kısıtlı bir kullanıcıyla çalıştırılmalıdır. Bir saldırgan konteyneri ele geçirirse, kök yetkisi olmadan zararı çok daha sınırlı kalır.
  • En az ayrıcalık ve yetenek kısıtlama. Bir konteynere yalnızca ihtiyacı olan Linux yetenekleri (capabilities) verilmeli, gereksiz sistem çağrılarına erişim kısıtlanmalıdır.
  • Salt okunur dosya sistemi. Mümkün olan durumlarda, konteynerin dosya sistemi salt okunur yapılmalı, böylece bir saldırgan konteyner içine kalıcı bir değişiklik yazamaz.
  • Kaynak sınırlama. Bir konteynere CPU ve bellek sınırları koymak, hem performans hem güvenlik açısından önemlidir, çünkü sınırsız bir konteyner, ele geçirildiğinde tüm ana makineyi tüketebilir.
Katman Ana risk Temel önlem
İmaj Bilinen zafiyet, kötü niyetli imaj Tarama, minimal imaj, güvenilir kaynak
Çalışma zamanı Konteynerden kaçış, ayrıcalık yükseltme Kök olmayan kullanıcı, yetenek kısıtlama
Kubernetes kümesi API erişimi, pod'lar arası yayılma RBAC, ağ politikaları, kimlik doğrulama
Sırlar Gömülü parola ve anahtar Sır yönetim aracı, asla imaja gömmeme

Kubernetes küme güvenliği

Kubernetes, konteynerleri büyük ölçekte yönetirken, kendi başına geniş bir saldırı yüzeyi taşır. Kümenin güvenliği birkaç temel alanda kurulur.

  • API sunucusu erişimi. Kubernetes API sunucusu, kümenin kontrol merkezidir. Buraya erişim sıkı kimlik doğrulama ve yetkilendirme ile korunmalı, asla açık internete maruz bırakılmamalıdır.
  • Rol tabanlı erişim kontrolü (RBAC). Her kullanıcı ve servise, yalnızca ihtiyacı olan en dar yetki verilmelidir. Aşırı geniş yetkiler, bir hesabın ele geçirilmesi durumunda tüm kümeyi riske atar.
  • Ağ politikaları. Varsayılan olarak, bir kümedeki tüm pod'lar birbiriyle konuşabilir. Ağ politikaları, hangi pod'un hangisiyle konuşabileceğini sınırlar, böylece bir pod ele geçirilse bile saldırgan tüm kümeye yayılamaz.
  • Ad alanı (namespace) izolasyonu. Farklı ekiplerin ya da uygulamaların kaynaklarını ayrı ad alanlarında tutmak, hem düzeni sağlar hem yanlışlıkla ya da kötü niyetli erişimi sınırlar.
  • Denetim günlükleri. Kümedeki tüm önemli işlemler günlüğe kaydedilmeli ve izlenmelidir, böylece olağandışı bir erişim ya da yapılandırma değişikliği hızla fark edilir.

Sırların yönetimi, en sık yapılan hata

Konteyner dünyasında en sık görülen hata, veritabanı parolaları, API anahtarları ve sertifikaların konteyner imajına ya da düz metin ortam değişkenine gömülmesidir. Bir imaj bir kez paylaşıldığında ya da bir kayıt defterine yüklendiğinde, içindeki sır artık sızmış sayılır. Sızan sırların gerçek etkilerini ve önlenmesini sızan API anahtarları ve sırlar yazımızda ayrıntılı anlattık.

Doğru yaklaşım, sırları koddan ve imajdan tamamen ayrı tutmaktır. Kubernetes kendi sır yönetimi mekanizmasını sunar, ama daha güçlü bir kurulum için özel bir sır yönetim aracı kullanmak, erişimi yetkiyle sınırlamak ve sırları düzenli olarak yenilemek (rotasyon) gerekir.

Konteyner ve Kubernetes güvenlik kontrol listesi

Bir konteyner ortamını üretime almadan önce şu maddeleri doğrulayın.

  • Tüm imajlar dağıtılmadan önce otomatik olarak zafiyet taramasından geçiyor mu?
  • İmajlar yalnızca güvenilir ve doğrulanmış kaynaklardan mı alınıyor?
  • Konteynerler kök olmayan bir kullanıcıyla mı çalışıyor?
  • Kubernetes API sunucusu sıkı kimlik doğrulamayla korunuyor ve açık internete kapalı mı?
  • RBAC doğru yapılandırılmış, her kullanıcı ve servise en az ayrıcalık mı veriliyor?
  • Ağ politikaları pod'lar arası gereksiz trafiği kısıtlıyor mu?
  • Sırlar konteyner imajına ya da düz metin ortam değişkenine gömülü değil, ayrı bir sır yönetim aracında mı tutuluyor?
  • Kümedeki işlemler günlüğe kaydediliyor ve düzenli izleniyor mu?

Bu listeyi tamamlayan bir konteyner ortamı, hem hızlı hem güvenli çalışır. DSET olarak konteyner ve Kubernetes altyapılarını bu çerçeveyle denetliyor ve sertleştiriyoruz. Kurumsal firewall ve ağ güvenliğinin genel çerçevesini kurumsal firewall seçimi, NGFW rehberi yazımızda da ele aldık.

Konteynerden kaçış, en ciddi tehdit

Konteyner güvenliğinin en ciddi senaryosu, konteynerden kaçıştır (container escape). Bir saldırgan, bir uygulamadaki zafiyeti kullanarak konteynerin izolasyonunu aşar ve ana makineye (host) doğrudan erişim kazanır. Bu gerçekleştiğinde, saldırgan artık tek bir konteynerle sınırlı değildir, o ana makinede çalışan tüm diğer konteynerlere ve kümenin geri kalanına erişebilir.

Konteynerden kaçışın en yaygın nedenleri şunlardır. Konteynerin kök (root) yetkisiyle çalıştırılması, kaçış durumunda saldırgana ana makinede de kök yetkisi verir. Gereksiz Linux yeteneklerinin (capabilities) tanımlanması, saldırgana çekirdek seviyesinde işlem yapma imkanı sunar. Ayrıcalıklı (privileged) modda çalışan konteynerler, izolasyonun büyük bölümünü devre dışı bırakır ve neredeyse doğrudan ana makine erişimi sağlar. Ve güncel olmayan bir konteyner çalışma zamanı (runtime), bilinen kaçış zafiyetlerine karşı savunmasız kalır.

Bu riski azaltmanın yolu, önceki bölümde anlatılan çalışma zamanı sertleştirmesini tavizsiz uygulamaktır, kök olmayan kullanıcı, en az ayrıcalık, ayrıcalıklı modun kaçınılması ve çalışma zamanının güncel tutulması. Ek olarak, konteyner çalışma zamanı düzeyinde anormal davranışı tespit eden bir izleme katmanı, bir kaçış denemesini gerçek zamanlı yakalayabilir.

CI/CD hattında güvenlik, sola kaydırma

Konteyner güvenliğinin en etkili uygulandığı nokta, konteyner üretime çıkmadan önceki derleme hattıdır (CI/CD). Buna güvenliği sola kaydırma (shift left) denir, sorunu üretimde yakalamak yerine, geliştirme sürecinin en başında önlemek.

Pratikte bu, birkaç otomatik kapıdan geçmek demektir. Bir imaj derlenirken otomatik olarak zafiyet taramasından geçirilir, ve kritik bir zafiyet bulunursa derleme durdurulur. Kubernetes yapılandırma dosyaları (manifest), üretime uygulanmadan önce yanlış yapılandırmalara karşı taranır, örneğin bir pod'un ayrıcalıklı modda tanımlanıp tanımlanmadığı otomatik kontrol edilir. Ve imaj, yalnızca belirlenen güvenlik eşiğini geçtiğinde kayıt defterine (registry) yüklenir. Bu otomatik kapılar, insan hatasının üretime sızmasını büyük ölçüde engeller. Derleme hattı güvenliğinin genel çerçevesini tedarik zinciri saldırıları yazımızda da ele aldık.

Mikroservis mimarisinde güvenlik, ek bir katman

Kubernetes, çoğu zaman bir mikroservis mimarisiyle birlikte kullanılır, bir uygulama onlarca küçük, bağımsız servise bölünür. Bu mimari esneklik sağlar ama güvenlik açısından ek bir karmaşıklık getirir, çünkü artık korunması gereken tek bir uygulama değil, birbiriyle sürekli konuşan onlarca servis vardır.

Bu ortamda iki ilke öne çıkar. Servisler arası kimlik doğrulama, bir servisin diğerine bağlanırken kim olduğunu kanıtlamasıdır, böylece ele geçirilmiş bir servis diğerlerini taklit edemez. Bir hizmet ağı (service mesh), servisler arası tüm trafiği şifreler ve kimlik doğrular, bu da mikroservisler arasında güvenli iletişimi merkezi olarak yönetmenin bir yoludur. Doğru kurulduğunda, bir mikroservis ele geçirilse bile, saldırganın diğer servislere sıçraması çok daha zorlaşır.

Sıkça Sorulan Sorular

Konteynerler sanal makinelerden daha mı az güvenli? Doğası gereği değil, ama farklı bir tehdit modeli taşır. Konteynerler ana makinenin çekirdeğini paylaştığı için izolasyon sanal makinelere göre daha zayıftır, bu yüzden çalışma zamanı sertleştirmesi (kök olmayan kullanıcı, yetenek kısıtlama) kritik önem taşır.

Küçük bir ekip Kubernetes güvenliğini nasıl önceliklendirmeli? En kritik üç adım, API sunucusunu açık internete kapatmak, RBAC ile en az ayrıcalık ilkesini uygulamak ve sırları asla koda ya da imaja gömmemektir. Bunlar, en düşük efor ile en yüksek riski azaltan adımlardır.

İmaj taraması yeterli mi, çalışma zamanı izleme gerekir mi? Hayır, ikisi de gereklidir. İmaj taraması bilinen zafiyetleri dağıtımdan önce yakalar, ama bir konteyner çalışırken oluşan anormal davranışı (beklenmedik ağ bağlantısı, yetki yükseltme denemesi) yalnızca çalışma zamanı izleme yakalayabilir.

Sırları Kubernetes'in kendi mekanizmasında tutmak yeterli mi? Temel bir koruma sağlar, ama üretim ortamlarında özel bir sır yönetim aracı, daha güçlü şifreleme, erişim kontrolü ve otomatik rotasyon gibi ek katmanlar sunar. Kritik sistemlerde bu ek katman önerilir.

Kaynaklar

Konteyner ve Kubernetes altyapınızı güvenlik açıkları, yanlış yapılandırma ve sır yönetimi açısından denetlemek için DSET ile iletişime geçin.