Container ve Kubernetes Güvenliği Temelleri

Container'lar (Docker gibi) ve bunları YÖNETEN Kubernetes gibi orkestrasyon sistemleri, modern bulut uygulamalarının OMURGASINI oluşturuyor. Ama bu yeni katman, GELENEKSEL sunucu güvenliğinden FARKLI, kendine özgü riskler de getiriyor.

Container Nedir? Hızlı Bir Hatırlatma

Bir container, bir uygulamayı ve TÜM bağımlılıklarını (kütüphaneler, ayarlar) TEK BİR paket hâlinde İZOLE eden hafif bir sanallaştırma birimidir — geleneksel bir sanal makineden FARKLI olarak, container'lar işletim sisteminin ÇEKİRDEĞİNİ (kernel) HOST ile PAYLAŞIR, bu da onları çok daha HAFİF ve HIZLI başlatılabilir yapar.

Container İmaj Güvenliği: Tedarik Zinciri Riski

Malware Analizi kütüphanemizdeki "Tedarik Zinciri Saldırıları" kavramının container dünyasındaki KARŞILIĞI, GÜVENSİZ container imajları kullanmaktır:

• Docker Hub gibi genel imaj deposundan, DOĞRULANMAMIŞ, kaynağı BELİRSİZ bir imaj çekmek, o imajın İÇİNDE ZATEN gömülü zararlı kod olma riskini taşır.
• İmaj taraması (image scanning): Trivy, Clair gibi araçlar, bir container imajının İÇİNDEKİ bilinen zafiyetleri (eski, güncellenmemiş kütüphaneler) OTOMATİK olarak tarayabilir — bu, Malware Analizi kütüphanemizdeki "Zafiyetli ve Güncel Olmayan Bileşenler" makalesinin container bağlamındaki UYGULAMASIDIR.

Container Kaçışı (Container Escape)

Container'lar HOST çekirdeğini paylaştığı için, TEORİK olarak bir saldırganın container İÇİNDEN, HOST sistemine "kaçması" (escape) MÜMKÜN olabilir — bu, bir önceki bulut mimarisi makalemizde bahsettiğimiz izolasyon risklerinin EN CİDDİ örneklerinden biridir. Bu riski AZALTMAK için:

• Container'ları root olmayan bir kullanıcıyla çalıştırmak (çoğu container VARSAYILAN olarak root ile çalışır — bu GEREKSİZ bir risktir).
• Privileged mode'u (container'a HOST üzerinde neredeyse SINIRSIZ yetki veren bir ayar) SADECE KESİNLİKLE gerekliyse kullanmak.
• Runtime güvenlik araçları (Falco gibi) ile, container İÇİNDEKİ ŞÜPHELİ davranışları GERÇEK ZAMANLI izlemek.

Kubernetes'e Özgü Riskler

Kubernetes, YÜZLERCE container'ı YÖNETEN bir orkestrasyon platformu olduğu için, kendi ÖZEL güvenlik yüzeyine sahiptir:

• RBAC (Role-Based Access Control): Kubernetes'teki HER kullanıcı/servis hesabının, SADECE gerektiği kadar yetkiye sahip olması — bulut IAM makalemizdeki "en az yetki" ilkesinin Kubernetes karşılığı.
• Network Policies: VARSAYILAN olarak, bir Kubernetes cluster'ındaki TÜM pod'lar (container grupları) birbirleriyle SERBESTÇE konuşabilir — Ağ Güvenliği kütüphanemizdeki segmentasyon ilkesi burada da UYGULANMALI, gereksiz pod-to-pod iletişimi KISITLANMALIDIR.
• Secrets Management: API anahtarları, şifreler gibi hassas bilgilerin, container İMAJININ İÇİNE gömülmek yerine, Kubernetes'in KENDİ "Secrets" mekanizmasıyla (veya HashiCorp Vault gibi harici araçlarla) YÖNETİLMESİ.

Pratik Senaryo

Bir şirket, bir Kubernetes cluster'ında container'larını VARSAYILAN ayarlarla (root kullanıcı, kısıtlanmamış network policy) çalıştırıyor. Web uygulamasındaki bir zafiyet üzerinden BİR container ELE GEÇİRİLİYOR. Network policy KISITLAMASI olmadığı için, saldırgan bu container ÜZERİNDEN, cluster'daki DİĞER TÜM pod'lara (veritabanı dahil) SERBESTÇE erişebiliyor — TEK bir container'ın ele geçirilmesi, TÜM cluster'ın ele geçirilmesi anlamına geliyor. Eğer network policy'ler baştan doğru yapılandırılsaydı (her pod SADECE konuşması GEREKEN diğer pod'larla iletişim kurabilseydi), hasar TEK bir container ile SINIRLI kalabilirdi.

Nasıl Önlenir?

• Container imajlarını DAİMA taramak, güvenilir kaynaklardan çekmek.
• Container'ları root OLMAYAN kullanıcıyla çalıştırmak.
• Kubernetes RBAC ve Network Policy'leri, en az yetki ilkesine göre SIKI şekilde yapılandırmak.
• Hassas bilgileri özel secret yönetim araçlarıyla yönetmek, ASLA imaja gömmemek.

Bu makale, container ve Kubernetes güvenliğinin orta-ileri seviye teknik bir özetidir; siber-arsiv ekibi tarafından hazırlanmış özgün içeriktir.