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

Kubernetes Güvenliğine Giriş ve Katmanlı Savunma Stratejisi

Modern bulut bilişim dünyasında, konteyner orkestrasyonu denildiğinde akla gelen ilk isim şüphesiz Kubernetes (K8s) olmaktadır. Ancak bu güçlü araç, karmaşıklığıyla birlikte ciddi güvenlik risklerini de beraberinde getirmektedir. Kubernetes güvenliğini anlamak için öncelikle "Cloud Native" güvenliğinin temel taşı olan 4C Modeli (Cloud, Cluster, Container, Code) üzerinden düşünmek gerekir. Her katman, bir üsttekini koruyan bir zırh görevi görür. Eğer bulut altyapınız (Cloud) güvensizse, kümenizin (Cluster) ne kadar iyi yapılandırıldığının bir önemi kalmaz. Bu makalede, bir DevSecOps perspektifiyle, Kubernetes ortamlarınızı nasıl kurşun geçirmez hale getirebileceğinizi ve en sık yapılan ölümcül hataları inceleyeceğiz.

API Server Güvenliği: Kümenin Kapılarını Kilitlemek

Kubernetes mimarisinin kalbi kube-apiserver bileşenidir. Tüm yönetimsel işlemler bu API üzerinden gerçekleştirilir. Bu nedenle, API sunucusuna erişimin kısıtlanması güvenliğin birinci kuralıdır. İlk adım olarak, API sunucusunun halka açık internete kapalı olduğundan emin olunmalıdır. Firewall kuralları veya VPC içindeki özel ağlar (Private Subnets) kullanılarak erişim sadece belirli IP adreslerine veya VPN hatlarına indirgenmelidir.

Erişim kontrolünde ise RBAC (Role-Based Access Control) kullanımı hayati önem taşır. Çoğu organizasyonun yaptığı en büyük hata, kullanıcılara veya servis hesaplarına gereğinden fazla yetki vermektir. "Principle of Least Privilege" (En Az Yetki İlkesi) uyarınca, her kullanıcıya sadece işini yapabileceği kadar yetki tanımlanmalıdır. ClusterRoleBinding yerine mümkün olduğunca RoleBinding kullanarak yetkileri belirli bir Namespace ile sınırlandırmak, olası bir sızıntının tüm kümeye yayılmasını önleyecektir.

Ağ Güvenliği ve Network Policies

Varsayılan kurulumda Kubernetes, küme içindeki tüm Pod'ların birbirleriyle herhangi bir kısıtlama olmaksızın iletişim kurmasına izin verir. Bu durum, saldırganın bir Pod'u ele geçirdiğinde tüm ağda serbestçe hareket edebileceği (Lateral Movement) anlamına gelir. Bu riski bertaraf etmek için Network Policies kullanılmalıdır.

İyi bir ağ güvenlik stratejisi "Default Deny" kuralı ile başlar. Yani, aksi belirtilmediği sürece tüm giriş (Ingress) ve çıkış (Egress) trafikleri engellenmelidir. Ardından, sadece mikroservislerin ihtiyaç duyduğu spesifik bağlantılara izin verilmelidir. Örneğin, bir Frontend servisinin doğrudan Database servisine erişmesi engellenmeli, iletişim sadece Backend servisi üzerinden sağlanmalıdır. Ayrıca, Calico, Cilium veya Weave gibi gelişmiş bir CNI (Container Network Interface) eklentisi kullanarak ağ trafiğini şifrelemek ve daha derin denetimler yapmak mümkündür.

Container İmaj Güvenliği ve Tedarik Zinciri

Güvenlik daha kod yazılma aşamasında başlar. Container Image'larınızın güvenliği için şu adımlar kritik öneme sahiptir:

• Minimal Base Images: Mümkünse Alpine Linux veya Distroless imajlar kullanın. İmaj içinde ne kadar az araç (shell, curl, package manager) bulunursa, saldırı yüzeyi o kadar küçük olur.
• Vulnerability Scanning: İmajlarınızı CI/CD süreçlerinde Trivy, Clair veya Anchore gibi araçlarla tarayın. Kritik (Critical) seviyede açık barındıran imajların dağıtımına izin vermeyin.
• Image Signing: Cosign veya Notary kullanarak imajlarınızı dijital olarak imzalayın. Kubernetes kümenizde sadece güvenilir kaynaklardan gelen ve imzalanmış imajların çalışmasını zorunlu kılmak için Admission Controllers kullanın.

Pod Güvenliği ve Runtime Koruması

Pod'ların çalışma anındaki (runtime) davranışları, güvenliğin en dinamik kısmıdır. Kubernetes 1.25 sürümü ile birlikte tamamen hayatımıza giren Pod Security Admission (PSA), eski Pod Security Policies'in yerini almıştır. PSA kullanarak, kümenizde Privileged (ayrıcalıklı) konteynerlerin çalışmasını engelleyebilirsiniz.

Bir konteynerin Root kullanıcısı ile çalışması, yapılabilecek en büyük güvenlik hatalarından biridir. Konteyner içinde root haklarına sahip olan bir saldırgan, Container Escape teknikleriyle ana makineye (Node) sızabilir. Bu nedenle securityContext yapılandırmasında runAsNonRoot: true ve readOnlyRootFilesystem: true parametreleri mutlaka kullanılmalıdır. Ayrıca, çekirdek seviyesinde koruma sağlamak için AppArmor, SELinux veya Seccomp profilleri aktif edilmelidir.

Secret Yönetimi: Hassas Verileri Korumak

Kubernetes'in yerleşik Secret objeleri, varsayılan olarak sadece Base64 ile kodlanır, şifrelenmez. Bu, veritabanı şifrelerinizin veya API anahtarlarınızın etcd veritabanında düz metne çok yakın bir formatta saklandığı anlamına gelir. Bu riski yönetmek için şunlar yapılmalıdır:

• Encryption at Rest: Kubernetes API sunucusunda EncryptionConfiguration özelliğini aktif ederek verilerin etcd üzerinde şifreli saklanmasını sağlayın.
• External Secret Managers: Mümkünse HashiCorp Vault, AWS Secrets Manager veya Azure Key Vault gibi harici çözümleri External Secrets Operator veya Secrets Store CSI Driver aracılığıyla Kubernetes ile entegre edin.
• Environment Variables: Hassas verileri asla ortam değişkeni (Env Vars) olarak doğrudan podlara enjekte etmeyin; bunun yerine volume mounts yöntemini tercih edin.

Common Pitfalls: En Sık Yapılan Hatalar

Kubernetes yönetiminde tecrübeli ekiplerin bile zaman zaman düştüğü bazı tuzaklar vardır. Bunların başında Resource Limits (kaynak sınırları) tanımlamamak gelir. Bir podun sınırsız CPU ve RAM tüketmesine izin vermek, sadece performans sorunu değil, aynı zamanda bir DoS (Denial of Service) saldırısı riskidir. Bir saldırgan veya hatalı bir kod, tüm düğümün kaynaklarını tüketerek kümenin çökmesine neden olabilir.

Bir diğer yaygın hata, Dashboard gibi yönetim arayüzlerini şifresiz veya zayıf kimlik doğrulamasıyla dış dünyaya açmaktır. Geçmişteki pek çok büyük Kubernetes sızıntısı, yanlış yapılandırılmış Dashboard'lar üzerinden gerçekleşmiştir. Ayrıca, Node seviyesindeki güvenliği ihmal etmek de kritik bir hatadır. Kubernetes düğümlerinin işletim sistemi güncellemeleri düzenli yapılmalı ve SSH erişimi minimuma indirilmelidir.

İzleme ve Denetim (Logging & Auditing)

Güvenlik statik bir durum değil, sürekli bir süreçtir. Kümenizde neler olup bittiğini bilmeden onu koruyamazsınız. Audit Logs (Denetim Kayıtları), kimin, ne zaman, hangi API çağrısını yaptığını gösteren en değerli kaynaktır. Bu logların merkezi bir log yönetim sistemine (ELK, Splunk vb.) aktarılması ve şüpheli aktiviteler için alarmlar kurulması gerekir.

Çalışma zamanı tehdit tespiti için Falco gibi araçlar kullanmak, sistem çağrılarını (syscalls) izleyerek beklenmedik dosya erişimleri veya ağ bağlantıları gerçekleştiğinde sizi uyarır. Bu, "sıfırıncı gün" saldırılarını veya içeriden gelebilecek tehditleri fark etmek için hayati önem taşır.

Sonuç: Sürekli Güvenlik (DevSecOps)

Kubernetes güvenliği, kurulumdan sonra bir kez yapılıp unutulacak bir işlem değildir. CI/CD süreçlerine entegre edilmiş, otomatikleştirilmiş testler ve sürekli izleme ile desteklenmelidir. Altyapınızı Infrastructure as Code (IaC) prensipleriyle yönetirken, Checkov veya KICS gibi araçlarla konfigürasyon dosyalarınızdaki güvenlik açıklarını henüz üretim ortamına geçmeden yakalayabilirsiniz.

Unutmayın ki; en güvenli sistem, en az karmaşık olan ve her katmanında Sıfır Güven (Zero Trust) prensibini uygulayan sistemdir. Kubernetes'in sunduğu esnekliği güvenlik disipliniyle birleştirdiğinizde, sadece hızlı değil, aynı zamanda dayanıklı bir altyapı inşa etmiş olursunuz.