Kubernetes Güvenlik Kontrolleri Nasıl Yapılandırılır?
Mayıs 19, 2026
Cloud Native,Cloud Security,Siber Güvenlik,Siber Savunma
Kubernetes varsayılan kurulumları, hızlı geliştirme ve esneklik odaklı kurgulandığından güvenlik kontrolleri genellikle kapalı veya izin verici modda gelir; bu durum kontrol düzlemi ve veri düzleminde geniş saldırı yüzeyi oluşturur. Secure-by-design yaklaşımı, (1) Mimari izolasyon ile başlar: Kontrol düzlemi (API server, etcd, scheduler, controller-manager) ile iş yükü nodları ağ, erişim ve kaynak seviyesinde ayrıştırılır, multi-tenancy senaryolarında namespace ve pod güvenlik sınırları katmanlı şekilde tanımlanır. (2) Immutable altyapı kültürü benimsenir: Çalışma zamanı değişiklikleri yerine, güncellenmiş yapılandırmaların yeniden deployment’ı tercih edilir; bu sayede konfigürasyon drift riski ve kalıcı yetki yükseltme vektörleri minimize edilir. (3) Varsayılan reddetme (default-deny) politikası tüm katmanlara yayılır: Ağ trafiği, erişim istekleri ve pod çalıştırma izinleri açıkça izin verilmedikçe engellenir. Bu stratejik disiplin, cluster’ı “açık geliştirme platformu” olmaktan çıkarıp, “kontrollü üretim ortamı”na dönüştürür.
Teknik Kontroller ve Erişim Yönetimi
Kubernetes erişim yönetimi, kimlik doğrulama (authentication) ile yetkilendirme (authorization) katmanlarını sıkı şekilde ayırarak kurgulanmalıdır. Yapılandırma adımları: (1) Rol tabanlı erişim (RBAC) hiyerarşisi: `ClusterRole` yerine mümkün olduğunda `Role` kullanılır; yetkiler namespace kapsamına indirgenir, “ wildcard erişim yasaklanır. (2) ServiceAccount yönetimi: Her deployment için özel ServiceAccount tanımlanır; `automountServiceAccountToken: false` ile otomatik token mount varsayılan olarak kapatılır, yalnızca API erişimi gerektiren pod’larda manuel mount yapılır. (3) Düzenli erişim gözden geçirme: Kullanılmayan `ClusterRoleBinding`’ler, süresi dolan token’lar ve aşırı yetkili gruplar aylık otomatik tarama ile tespit edilir, iptal akışı başlatılır. (4) Just-in-Time (JIT) ve ayrıcalıklı erişim yönetimi: Admin/kubectl erişimleri için kalıcı yetki yerine, talep bazlı, süreli ve onaylı erişim verilir; oturumlar kayıt altına alınır. Bu yapı, kimlik kaynaklı saldırı yüzeyini daraltırken, operasyonel verimliliği korur.
Çalışma Zamanı Güvenliği ve İzleme
Kubernetes native `Secret` objeleri base64 encoded olduğu için şifrelenmiş değildir; güvenli yönetim için ek katmanlar zorunludur. Yapılandırma süreci: (1) etcd şifreleme at-rest: API server `–encryption-provider-config` parametresi ile yapılandırılır; AES-GCM veya KMS (AWS KMS, Azure Key Vault, HashiCorp Vault) provider kullanılarak etcd’deki tüm secret’lar şifrelenir. (2) Harici secret yönetimi entegrasyonu: `External Secrets Operator` veya `Vault Agent Injector` ile secret’lar merkezi güvenli depoda tutulur, Kubernetes’e yalnızca runtime’da enjekte edilir; rotation ve expiry yönetimi otomatik hale getirilir. (3) Pod seviyesinde erişim kısıtlama: Secret’lar environment variable yerine `volume mount` veya `projected service account token` ile sunulur; `readOnly: true` ve `defaultMode: 0400` ile dosya izinleri sınırlandırılır. (4) Denetim ve sızıntı önleme: `audit logging` ile secret erişim istekleri kaydedilir; `trivy` veya `kubescape` ile manifest ve git repo’lardaki hardcoded secret’lar taranır, CI’da otomatik engellenir. Bu katmanlı yaklaşım, credential sızıntısı riskini minimize ederken, uygulama uyumluluğunu korur.
Operasyonel Süreçler ve Sürekli İyileştirme
Düzenli tarama, yapılandırma drift ve yeni zafiyetleri erken tespit etmenin temel mekanizmasıdır. Tarama çerçevesi: (1) Komplians taraması (`kube-bench`): CIS Kubernetes Benchmark kuralları periyodik çalıştırılır; master/worker konfigürasyonları, dosya izinleri ve kubelet flag’leri doğrulanır, uyumsuzluklar ticket’a dönüştürülür. (2) Saldırı simülasyonu (`kube-hunter`): Internal ve external modlarda çalıştırılarak açık API endpoint’leri, aşırı yetkili service account’lar ve zayıf network policy’leri tespit edilir, red team perspektifiyle risk haritası çıkarılır. (3) Zafiyet ve drift taraması (`trivy`, `kubescape`): Cluster konfigürasyonu, container image’ları ve git manifest’leri tek platformda taranır; CVSS skoru, exploitability (EPSS) ve iş etkisi ile önceliklendirme yapılır. (4) Aksiyon döngüsü: Yüksek riskli bulgular 24-48 saat SLA ile kapatılır, orta/ düşük riskli iyileştirmeler roadmap’e eklenir; tarama sonuçları çeyreklik güvenlik komitesinde trend olarak izlenir. Bu disiplin, “tarama raporu biriktirme” alışkanlığını “operasyonel iyileştirme motoru”na dönüştürür.
Kubernetes güvenlik olgunluk modeli nasıl ölçülür ve sürekli iyileştirme döngüsü nasıl işletilir?
Olgunluk, tek seferlik kurulum değil, insan, süreç ve teknoloji boyutlarında kademeli gelişim gerektirir. Ölçüm ve iyileştirme çerçevesi: (1) Seviye tanımları: Initial (manuel yapılandırma, reaktif müdahale) → Managed (CIS taranmış, temel RBAC/NetworkPolicy) → Defined (Admission controller, PSS enforced, CI/CD entegrasyonu) → Measured (Runtime behavioral analysis, SOAR orkestrasyonu, metrik tabanlı SLA) → Optimizing (AI destekli drift prediction, otonom remediation, external threat intel sync). (2) Metrik takibi: Politika uyum skoru (%), audit log coverage, runtime alarm doğrulama oranı, upgrade compliance süresi ve developer security feedback skoru aylık dashboard’da görselleştirilir. (3) Sürekli iyileştirme mekanizmaları: Çeyreklik olgunluk değerlendirmesi ile eksikler roadmap’e eklenir; CKS (Certified Kubernetes Security Specialist) sertifikasyonları ve tabletop tatbikatları ile ekip yetkinliği artırılır; developer geri bildirim döngüsü ile güvenlik kontrollerinin “engelleme” algısı azaltılır. Bu döngü, Kubernetes güvenliğini “altyapı kurulumu” olmaktan çıkarıp, kurumun cloud-native dönüşümünün dinamik bir yetkinliğine dönüştürür.
Tags :
#KubernetesGüvenliği #CloudNative #DevSecOps #RBAC #NetworkPolicies #AdmissionController #Kyverno #OPA #Falco #ClusterHardening #SiberDirenç2026
Share This :