Kubernetes Güvenliği ve Mimari Tasarım: Kapsamlı Rehber

## Kubernetes Güvenliği: Modern Mimari Tasarım Stratejileri **Kubernetes güvenliği**, konteyner tabanlı orkestrasyon sistemlerinin üretim ortamlarında (production) sürdürülebilirliği için en kritik bileşendir. Mimari tasarım aşamasında güvenliği bir eklenti olarak değil, sistemin temel taşı olarak ele almak, saldırı yüzeyini (attack surface) minimize etmenin tek yoludur. Bu rehberde, bir Kubernetes kümesinin mimari olarak nasıl sertleştirileceğini, **Zero Trust** (Sıfır Güven) prensiplerinin nasıl uygulanacağını ve bileşenler arası iletişimin nasıl izole edileceğini teknik detaylarıyla inceleyeceğiz. ## 1. Kubernetes Güvenlik Katmanları (4C Modeli) Kubernetes güvenliği bütünsel bir yaklaşım gerektirir. Mimari tasarımda genellikle "4C Güvenlik Modeli" kullanılır: 1. **Cloud (Bulut):** Altyapı, ağ ve fiziksel sunucu güvenliği. 2. **Cluster (Küme):** Kubernetes API server, etcd ve node güvenliği. 3. **Container (Konteyner):** İmaj tarama, runtime güvenliği. 4. **Code (Kod):** Uygulama seviyesindeki zafiyetler ve statik analiz. > **Kritik Not:** Kubernetes mimarisinde en zayıf halka tüm sistemi tehlikeye atar. Bu nedenle her katmanda savunma derinliği (defense-in-depth) stratejisi uygulanmalıdır. ## 2. Kontrol Düzlemi (Control Plane) Güvenliği Kubernetes kümesinin beyni olan Control Plane bileşenleri, en yüksek öncelikli koruma alanıdır. Özellikle **API Server** ve **etcd** veritabanının erişilebilirliği kısıtlanmalıdır. ### API Server Erişimi API Server, dış dünyaya açık olmamalıdır. Sadece yetkili IP adreslerinden (Whitelisting) veya bir VPN/Bastion Host üzerinden erişilmelidir. ### etcd Şifreleme Etcd, kümedeki tüm verileri (Secret'lar dahil) tutar. Varsayılan olarak veriler diskte şifrelenmez. Mimari tasarımda `EncryptionConfiguration` mutlaka etkinleştirilmelidir. ```yaml apiVersion: apiserver.config.k8s.io/v1 kind: EncryptionConfiguration resources: - resources: - secrets providers: - aescbc: keys: - name: key1 secret: - identity: {} ``` ## 3. RBAC (Role-Based Access Control) Yapılandırması **RBAC**, Kubernetes mimarisinde "En Az Yetki Prensibi"ni (Principle of Least Privilege) uygulamak için kullanılır. Kullanıcılara ve ServiceAccount'lara sadece ihtiyaç duydukları kadar yetki verilmelidir. ### Örnek: Salt Okunur Rol Tanımı Aşağıdaki örnek, belirli bir namespace içindeki pod'ları listeleme yetkisi verir ancak silme veya değiştirme yetkisi tanımaz. ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: production name: pod-reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"] ``` Bu rolü bir kullanıcıya bağlamak için `RoleBinding` kullanılır: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: read-pods-binding namespace: production subjects: - kind: User name: "ahmet@kurum.com" apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io ``` ## 4. Network Policies ile Ağ İzolasyonu Kubernetes'te varsayılan olarak tüm pod'lar birbirleriyle konuşabilir. Bu, bir pod ele geçirildiğinde saldırganın ağda yatayda hareket etmesine (lateral movement) olanak tanır. Mimari tasarımda **Network Policies** kullanılarak "Default Deny" politikası uygulanmalıdır. ### Varsayılan Tüm Trafiği Engelleme (Default Deny) ```yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all namespace: default spec: podSelector: {} policyTypes: - Ingress - Egress ``` ### Belirli Bir Servise Erişim İzni Verme Sadece `frontend` etiketli pod'ların `backend` servisine 8080 portundan erişmesine izin veren kural: ```yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-frontend-to-backend namespace: production spec: podSelector: matchLabels: app: backend ingress: - from: - podSelector: matchLabels: app: frontend ports: - protocol: TCP port: 8080 ``` ## 5. Pod Security Admission (PSA) Kullanımı PodSecurityPolicies (PSP) kullanımdan kaldırıldıktan sonra yerini **Pod Security Admission** aldı. Bu sistem, namespace seviyesinde güvenlik standartlarını (Privileged, Baseline, Restricted) zorunlu kılar. ### Namespace Seviyesinde Kısıtlama Bir namespace'i en yüksek güvenlik seviyesine (Restricted) çekmek için: ```bash kubectl label --overwrite ns production-apps \ pod-security.kubernetes.io/enforce=restricted ``` ## 6. Güvenli Konteyner Çalıştırma Prensipleri Konteynerlerin root yetkileriyle çalışması büyük bir güvenlik açığıdır. Mimari tasarımda `securityContext` kullanımı zorunlu tutulmalıdır. ```yaml apiVersion: v1 kind: Pod metadata: name: secure-pod spec: securityContext: runAsNonRoot: true runAsUser: 1000 fsGroup: 2000 containers: - name: app image: my-app:1.0.0 securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL ``` ## 7. Secrets Management ve Hassas Veri Yönetimi Kubernetes Secret'ları varsayılan olarak sadece base64 ile kodlanır, şifrelenmez. Kurumsal mimarilerde şu yöntemler tercih edilmelidir: | Yöntem | Açıklama | Güvenlik Seviyesi | | :--- | :--- | :--- | | **Sealed Secrets** | GitOps dostu, asimetrik şifreleme kullanır. | Orta-Yüksek | | **HashiCorp Vault** | Dinamik secret üretimi ve merkezi yönetim. | Çok Yüksek | | **CSI Secret Store** | Cloud Provider (AWS, Azure, GCP) KMS entegrasyonu. | Yüksek | ## 8. Kaynak Sınırlandırma ve DoS Koruması Bir pod'un tüm node kaynaklarını tüketerek diğer servisleri durdurmasını (Denial of Service) engellemek için `ResourceQuotas` ve `LimitRanges` tanımlanmalıdır. ```yaml apiVersion: v1 kind: ResourceQuota metadata: name: compute-resources namespace: development spec: hard: requests.cpu: "4" requests.memory: 8Gi limits.cpu: "10" limits.memory: 16Gi ``` ## 9. Admission Controllers ve Otomasyon Politikaları manuel kontrol etmek yerine, **OPA Gatekeeper** veya **Kyverno** gibi Admission Controller araçları kullanılmalıdır. Örneğin; bir imajın sadece belirli bir registry'den (örn: `harbor.kurum.com`) çekilmesini zorunlu kılabilirsiniz. ```yaml # Kyverno Örneği: Root kullanıcıyı yasakla apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: disallow-root-user spec: validationFailureAction: enforce rules: - name: check-run-as-non-root match: resources: kinds: - Pod validate: message: "Root kullanıcı ile çalıştırmak yasaktır." pattern: spec: securityContext: runAsNonRoot: true ``` ## 10. Runtime Security ve İzleme Statik analizler yeterli değildir; çalışma anında (runtime) meydana gelen şüpheli hareketler izlenmelidir. **Falco** gibi araçlar, sistem çağrılarını (syscalls) dinleyerek anomali tespiti yapar. - Bir pod içinde `sh` veya `bash` çalıştırılması. - Beklenmedik bir dosya yazma işlemi. - Hassas dizinlere (/etc, /root) erişim. ## 11. Sık Yapılan Hatalar ve Kaçınılması Gerekenler 1. **Privileged: true Kullanımı:** Konteynerin host makinesindeki tüm yetkilere sahip olmasına neden olur. Kesinlikle kaçınılmalıdır. 2. **Default ServiceAccount Kullanımı:** Her pod'a varsayılan olarak bağlanan token, gereksiz yetki artışına yol açabilir. `automountServiceAccountToken: false` yapılmalıdır. 3. **Etiketlenmemiş İmajlar:** `latest` tag kullanımı, hangi kodun çalıştığının takibini zorlaştırır ve rollback işlemlerini imkansız kılar. 4. **Zayıf etcd Koruması:** etcd'nin API Server dışındaki her şeye açık olması tüm kümenin ele geçirilmesine neden olur. ## 12. Sık Sorulan Sorular (FAQ) **Soru 1: Kubernetes Secret'ları gerçekten güvenli mi?** Cevap: Hayır, varsayılan olarak sadece base64 ile kodlanırlar. Mimari tasarımda mutlaka KMS (Key Management Service) veya Vault entegrasyonu yapılmalıdır. **Soru 2: Network Policy kullanmak performansı etkiler mi?** Cevap: Çok düşük bir overhead (ek yük) getirir ancak sağladığı güvenlik faydası bu maliyetin çok üzerindedir. CNI eklentisine (Calico, Cilium vb.) bağlı olarak performans değişebilir. **Soru 3: Rootless konteyner nedir?** Cevap: Konteynerin hem host üzerinde hem de konteyner içinde root olmayan bir kullanıcı ile çalıştırılmasıdır. Bu, konteynerden kaçış (container escape) saldırılarını büyük ölçüde engeller. **Soru 4: RBAC'ta ClusterRole ve Role arasındaki fark nedir?** Cevap: Role belirli bir namespace ile sınırlıdır; ClusterRole ise tüm küme genelindeki kaynaklara (Nodes, Namespaces vb.) erişim sağlar. **Soru 5: CIS Benchmarks nedir?** Cevap: Kubernetes bileşenlerinin güvenli yapılandırılması için endüstri standardı olan bir kontrol listesidir. `kube-bench` aracı ile bu kontroller otomatikleştirilebilir. ## Özet ve Sonuç Kubernetes güvenliği, sürekli devam eden bir süreçtir. **RBAC**, **Network Policies** ve **Pod Security Standards** gibi yerleşik mekanizmaların doğru yapılandırılması, güvenli bir mimarinin temelini oluşturur. Modern sistemlerde bu yapılandırmalar GitOps süreçlerine dahil edilmeli ve otomatik araçlarla sürekli denetlenmelidir. Güvenliği tasarımın merkezine koyarak, hem uyumluluk (compliance) gereksinimlerini karşılayabilir hem de iş kritik uygulamalarınızı koruma altına alabilirsiniz.