Kubernetes Güvenliği: Best Practices ve Common Pitfalls

Kubernetes Güvenliğine Giriş ve Temel Yaklaşımlar

Bulut bilişim dünyasının standart orkestrasyon aracı haline gelen Kubernetes, karmaşık yapısı ve esnekliği nedeniyle siber saldırganlar için oldukça cazip bir hedef haline gelmiştir. Konteyner tabanlı mimarilerin yaygınlaşmasıyla birlikte, geleneksel güvenlik yöntemleri yetersiz kalmaya başlamış ve Cloud Native Security kavramı ön plana çıkmıştır. Kubernetes güvenliği sadece kümenin kendisini korumak değil, altyapıdan uygulama koduna kadar uzanan çok katmanlı bir savunma stratejisi gerektirir. Bu makalede, bir DevSecOps perspektifiyle Kubernetes ekosisteminde güvenliği nasıl sağlayacağınızı, en iyi uygulamaları ve sıkça düşülen hataları detaylandıracağız.

Cloud Native Güvenliğinin 4C Modeli

Kubernetes güvenliğini anlamak için öncelikle 4C Modeli olarak bilinen hiyerarşik yapıyı kavramak gerekir. Bu katmanlar sırasıyla Cloud (Bulut/Altyapı), Cluster (Küme), Container (Konteyner) ve Code (Kod) şeklindedir. Her katman bir üsttekine dayanır; dolayısıyla en alttaki altyapı katmanı güvensizse, üstteki Kubernetes yapılandırmasının ne kadar güçlü olduğunun bir önemi kalmaz. Cloud katmanında API erişim kısıtlamaları ve ağ izolasyonu, Cluster katmanında RBAC ve API Server güvenliği, Container katmanında imaj tarama ve Code katmanında ise statik analiz testleri (SAST) kritik rol oynar.

Kubernetes Küme Güvenliği: Best Practices

Bir Kubernetes kümesini sertleştirmek (hardening), saldırı yüzeyini minimize etmekle başlar. İşte bu süreçte uygulanması gereken temel teknik stratejiler:

1. API Server Güvenliği ve Erişim Kontrolü

Kubernetes API Server, kümenin beynidir ve tüm yönetimsel işlemler buradan geçer. Bu bileşenin güvenliğini sağlamak için şu adımlar hayati önem taşır:

• Public Erişimi Kapatın: API Server'ın internete açık olması en büyük risklerden biridir. Mümkünse sadece VPN veya belirli bir Jumpbox üzerinden erişime izin verilmeli, IP beyaz listesi (whitelisting) kullanılmalıdır.
• TLS Şifreleme: Tüm trafik TLS ile şifrelenmelidir. Sertifika otoritelerinin (CA) yönetimi ve rotasyonu düzenli olarak yapılmalıdır.
• Anonymus Auth Devre Dışı Bırakılmalı: --anonymous-auth=false bayrağı ile kimliği doğrulanmamış isteklerin API sunucusuna ulaşması engellenmelidir.

2. Role-Based Access Control (RBAC) Yapılandırması

RBAC, küme içindeki kullanıcıların ve servis hesaplarının (ServiceAccounts) neler yapabileceğini belirler. En iyi uygulama, Least Privilege (En Az Yetki) prensibidir.

• Cluster-Admin Yetkisini Sınırlandırın: Herkese cluster-admin rolü vermek yerine, sadece ihtiyaç duyulan namespace düzeyinde yetkilendirme (Role vs ClusterRole) yapılmalıdır.
• Default Service Accounts: Her namespace ile gelen varsayılan servis hesaplarına otomatik olarak geniş yetkiler atanmamalıdır. automountServiceAccountToken: false seçeneği ile podların API server ile gereksiz yere konuşması engellenmelidir.
• Periyodik Denetim: Kullanılmayan veya gereğinden fazla yetkiye sahip RoleBinding yapıları düzenli olarak kubectl-who-can gibi araçlarla denetlenmelidir.

3. Ağ Politikaları (Network Policies) ile İzolasyon

Kubernetes'te varsayılan olarak tüm podlar birbiriyle konuşabilir (Flat Network). Bu, bir pod ele geçirildiğinde saldırganın küme içinde yatayda hareket etmesine (Lateral Movement) olanak tanır.

• Default Deny All: Tüm trafiği engelleyen bir varsayılan politika oluşturulmalı ve ardından sadece gerekli olan trafik (Ingress ve Egress) açıkça tanımlanmalıdır.
• Namespace İzolasyonu: Farklı departmanların veya uygulamaların podları NetworkPolicy ile birbirlerinden izole edilmelidir.
• Service Mesh Kullanımı: Daha karmaşık yapılar için Istio veya Linkerd gibi araçlarla mTLS (Mutual TLS) uygulanarak podlar arası iletişim uçtan uca şifrelenmelidir.

4. Secret Yönetimi

Kubernetes Secrets nesneleri varsayılan olarak sadece Base64 ile kodlanır, yani şifrelenmezler. Bu, etcd veritabanına erişimi olan birinin tüm şifreleri, API anahtarlarını ve sertifikaları düz metin olarak görebileceği anlamına gelir.

• Encryption at Rest: etcd üzerindeki verilerin şifrelenmesi için EncryptionConfiguration aktif edilmelidir.
• Harici Çözümler: Hassas verileri saklamak için HashiCorp Vault, AWS Secrets Manager veya Azure Key Vault gibi harici KMS (Key Management Service) çözümleri entegre edilmelidir.

Konteyner ve Runtime Güvenliği

Kümenin güvenliğini sağlamak yetmez; içinde çalışan iş yüklerinin (workloads) de güvenli olması gerekir.

İmaj Güvenliği ve Tedarik Zinciri

Güvenlik, imajın oluşturulduğu CI/CD hattında başlar.

• Vulnerability Scanning: İmajlar, kayıt defterine (Registry) itilmeden önce Trivy, Clair veya Anchore gibi araçlarla taranmalıdır.
• Distroless İmajlar: İmajların içinde curl, apt, sh gibi saldırganların işine yarayacak araçlar bulunmamalıdır. Sadece uygulamanın çalışması için gereken minimal kütüphaneleri içeren Distroless veya Alpine bazlı imajlar tercih edilmelidir.
• Image Signing: Cosign veya Notary gibi araçlarla imajlar imzalanmalı ve küme içinde sadece doğrulanmış imajların çalışmasına izin veren Admission Controller mekanizmaları kurulmalıdır.

Pod Security Standards (PSS) ve Admission Control

Eski PodSecurityPolicy (PSP) yerine gelen Pod Security Admission, podların uyması gereken güvenlik kurallarını belirler.

• Privileged Konteynerleri Yasaklayın: Bir konteynerin host makinenin yetkilerine sahip olması (privileged: true) engellenmelidir.
• Root Kullanımını Engelleyin: Konteynerler asla root kullanıcısı ile çalışmamalıdır. runAsNonRoot: true ve allowPrivilegeEscalation: false parametreleri SecurityContext içinde tanımlanmalıdır.
• Read-Only Root Filesystem: Konteynerin dosya sistemi salt okunur (read-only) yapılarak, saldırganın çalışma anında zararlı yazılım indirmesi zorlaştırılmalıdır.

Kubernetes Güvenliğinde Sık Yapılan Hatalar (Common Pitfalls)

Deneyimli ekiplerin bile sıkça düştüğü bazı tuzaklar, tüm güvenlik mimarisini çökertebilir:

1. etcd Veritabanının Korunmaması

etcd, Kubernetes'in tüm durum bilgisini sakladığı yerdir. Eğer bir saldırgan etcd'ye erişirse, kümenin tamamını ele geçirmiş sayılır. etcd'nin sadece API Server ile konuşması sağlanmalı ve mutlaka mTLS ile korunmalıdır. Ayrıca, etcd yedeklerinin de şifrelenmiş bir şekilde saklanması unutulmamalıdır.

2. Dashboard ve Monitoring Araçlarının Açık Bırakılması

Kubernetes Dashboard, geçmişte birçok büyük sızıntının kaynağı olmuştur. Eğer kullanılması zorunlu değilse Dashboard tamamen kaldırılmalıdır. Kullanılacaksa da mutlaka güçlü bir kimlik doğrulama arkasına alınmalı ve dış dünyaya açık olmamalıdır.

3. Kaynak Limitlerinin Belirlenmemesi

Güvenlik sadece veri hırsızlığı değildir, aynı zamanda sistemin erişilebilir olmasıdır. Resource Quotas ve LimitRanges tanımlanmamış bir kümede, tek bir saldırgan pod veya hatalı bir uygulama tüm node kaynaklarını (CPU/RAM) tüketerek Denial of Service (DoS) durumuna yol açabilir.

4. Varsayılan Namespace Kullanımı

Tüm uygulamaları default namespace içinde çalıştırmak, mantıksal izolasyonu imkansız hale getirir. Her uygulama veya mikroservis grubu kendi namespace'ine sahip olmalı ve RBAC/NetworkPolicy sınırları buna göre çizilmelidir.

İzleme, Denetim ve Olay Müdahalesi

Güvenlik statik bir durum değil, sürekli bir süreçtir. Observability araçları bu sürecin ayrılmaz parçasıdır.

Audit Logs: Kubernetes API sunucusu tarafından üretilen denetim kayıtları (audit logs), "Kim, ne zaman, hangi işlemi yaptı?" sorusuna yanıt verir. Bu günlükler merkezi bir SIEM çözümüne (Elasticsearch, Splunk vb.) aktarılmalı ve şüpheli aktiviteler için alarmlar kurulmalıdır.

Runtime Security Monitoring: Konteynerlerin çalışma anındaki davranışlarını izlemek için Falco gibi araçlar kullanılmalıdır. Falco, beklenmedik bir dosya erişimi, ağ bağlantısı veya bir konteyner içinde shell açılması gibi durumları gerçek zamanlı olarak tespit edebilir.

Sonuç

Kubernetes güvenliği, "kur ve unut" mantığıyla yönetilemeyecek kadar dinamik bir alandır. Başarılı bir güvenlik stratejisi, Shift-Left yaklaşımını benimseyerek güvenliği yazılım geliştirme yaşam döngüsünün (SDLC) en başına dahil etmelidir. Altyapı katmanından başlayarak, RBAC yapılandırması, ağ izolasyonu, imaj tarama ve sürekli izleme ile desteklenen bir Defense in Depth (Derinlemesine Savunma) mimarisi, Kubernetes kümelerinizi modern tehditlere karşı dirençli kılacaktır. Unutmayın ki en zayıf halka kadar güvendesiniz; bu nedenle her katmanda sıkılaştırma ve denetim yapmak bir tercih değil, zorunluluktur.