K8s Cluster'ı Kendi Ellerinizle Teslim Etmenin Yolları: Konfigürasyon Hataları ve Sert Gerçekler

bash\ncurl -k -H \"Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)\" https://127.0.0.1:6443/api/v1/namespaces/default/secrets\n\n\nBu komut bir pod'un içinden başarıyla yanıt döndürüyorsa, geçmiş olsun; cluster'ın anahtarlarını paspasın altına bırakmışsınız demektir. Kubernetes (K8s) dünyasına hoş geldin dostum. Burası her şeyin çok hızlı çalıştığı, ölçeklendiği ama aynı zamanda tek bir YAML satırıyla tüm altyapının 'public' hale gelebildiği bir vahşi batı.\n\nBugün seninle testCompany'deki operasyonlarımızda sıkça karşılaştığımız, Red Team gözüyle baktığımızda iştahımızı kabartan ama savunma tarafında uykularımızı kaçıran o kritik konfigürasyon hatalarını konuşacağız. Kahveni al, çünkü 'default' ayarlara güvenmenin bedelini sahada çok ağır ödeyenler var.\n\n### 1. RBAC: Cluster'ın Anahtarlarını Herkese Dağıtmak\n\nRole-Based Access Control (RBAC), K8s güvenliğinin kalbidir. Ama genelde nasıl oluyor? 'Abi developer'lar hata alıyormuş, şu ServiceAccount'a bir Cluster-Admin verelim de işleri yürüsün' deniliyor. İşte o an, pimi çekilmiş bir bombayı cluster'ın ortasına bırakıyorsun.\n\nSaldırgan bir pod'u ele geçirdiğinde ilk yaptığı şey /var/run/secrets/kubernetes.io/serviceaccount/token dosyasına bakmaktır. Eğer bu token aşırı yetkili bir ClusterRoleBinding ile ilişkilendirilmişse, saldırgan artık senin cluster admin'indir. \n\nKötü Senaryo (Örnek):\n\nyaml\napiVersion: rbac.authorization.k8s.io/v1\nkind: ClusterRoleBinding\nmetadata:\n name: read-everything-everywhere\nsubjects:\n- kind: ServiceAccount\n name: default\n namespace: app-namespace\nroleRef:\n kind: ClusterRole\n name: view # Veya daha kötüsü 'cluster-admin'\n apiGroup: rbac.authorization.k8s.io\n\n\nBuradaki tehlike, default servis hesabına verilen geniş yetkilerdir. \n\nNe Yapmalı?\n- Least Privilege: Her pod için sadece ihtiyacı olan yetkilere sahip spesifik bir ServiceAccount tanımla.\n- AutomountServiceAccountToken: Eğer pod'un K8s API ile konuşmasına gerek yoksa, automountServiceAccountToken: false ayarını yap. Neden durduk yere token'ı içeri mount edesin ki?\n\n### 2. Privileged Container: Host Sistemine Giden Kısa Yol\n\nBir container'ın privileged: true olarak çalıştırılması demek, o container'ın içindeki root kullanıcısının host üzerindeki root ile neredeyse aynı yetkilere sahip olması demektir. Bir saldırgan bu pod'u ele geçirdiğinde, container'dan 'escape' (kaçış) yapması saniyeler sürer.\n\nyaml\nspec:\n containers:\n - name: insecure-container\n image: example.com/app:latest\n securityContext:\n privileged: true # İntihar fermanı\n\n\nSaldırgan buradan sonra mount /dev/sda1 /mnt/host diyerek host makinenin diskini içeri bağlar ve chroot ile host'un efendisi olur. K8s katmanı artık devre dışıdır, doğrudan fiziksel veya sanal sunucunun içindedir.\n\nÇözüm:\n- Pod Security Admissions (PSA) veya Gatekeeper gibi araçlarla privileged container kullanımını tamamen yasakla.\n- İlla ki bir yetki gerekiyorsa capabilities kullan ve sadece gereken yetkiyi (örn: NET_ADMIN) ver.\n\n### 3. Network Policy: İçeride At Koşturmak\n\nVarsayılan olarak K8s içindeki her pod, diğer her pod ile konuşabilir. Bir mikroservisin DB'ye erişmesi normalken, dış dünyaya açık basit bir frontend pod'unun 'kube-system' namespace'indeki pod'lara veya internal monitoring araçlarına erişmesi normal değildir.\n\nNetwork Policy tanımlanmamış bir cluster'da lateral movement (yanal ilerleme) çocuk oyuncağıdır. Saldırgan zayıf bir pod'u hackler, oradan cluster içindeki tüm trafiği sniff eder veya zayıf servisleri tarar.\n\nZararsızlaştırılmış Örnek Policy:\n\nyaml\nkind: NetworkPolicy\napiVersion: networking.k8s.io/v1\nmetadata:\n name: allow-only-db\n namespace: app-backend\nspec:\n podSelector:\n matchLabels:\n app: database\n ingress:\n - from:\n - podSelector:\n matchLabels:\n app: backend-api\n\n\nBu policy der ki: "Database'e sadece backend-api etiketli pod'lar gelebilir, başka kimse kapıyı çalmasın." İşte bu kadar basit ama hayat kurtarıcı bir hamle.\n\n### 4. Secret Management: Base64 Şifreleme Değildir!\n\nBunu hala söylüyoruz çünkü hala yapılıyor. K8s Secret objeleri varsayılan olarak etcd üzerinde şifrelenmeden tutulur. Sadece Base64 ile encode edilmiştir. Bu bir güvenlik önlemi değil, sadece bir veri formatıdır.\n\necho "cGFzc3dvcmQxMjM=" | base64 --decode yaptığında şifre karşındadır. Eğer etcd erişimini kaybedersen veya cluster yedeğini (backup) korumasız bırakırsan tüm secret'ların ifşa olur.\n\nGüvenli Yol:\n- Encryption at Rest: K8s API server üzerinde EncryptionConfiguration aktif ederek verilerin etcd'ye yazılırken şifrelenmesini sağla.\n- External Secrets: HashiCorp Vault veya AWS Secrets Manager gibi profesyonel çözümleri kullan ve ExternalSecrets operatörü ile bunları K8s'e besle.\n\n### 5. HostPath Mount: Dosya Sistemine Arka Kapı\n\nPod'un içine host sisteminden bir dizin mount etmek (hostPath), özellikle /etc, /var/run/docker.sock veya /root gibi dizinleri mount etmek tam bir güvenlik kabusudur. \n\nÖzellikle docker.sock mount edildiğinde, pod içindeki bir saldırgan host üzerinde yeni container'lar oluşturabilir, mevcutları silebilir ve aslında host'un Docker yetkilerine sahip olur.\n\nyaml\nvolumeMounts:\n- mountPath: /var/run/docker.sock\n name: docker-socket\n\n\nEğer bunu görüyorsan, orada büyük bir risk vardır. Modern K8s cluster'larında (CRI-O veya containerd kullananlar) bu artık daha zor olsa da, mantık aynı: Host ile container arasındaki izolasyonu bozma.\n\n### Saha Notu ve Tavsiyeler\n\nK8s güvenliği bir kerelik bir 'check-list' değildir. Sürekli bir hardening sürecidir. Biz testCompany'de Red Team olarak sızmaya çalıştığımızda, genelde en zayıf halka 'unutulmuş pod'lar' veya 'test için açılmış geniş yetkili servis hesapları' oluyor.\n\nCluster'ını korumak istiyorsan şu 3'lüye odaklan:\n1. İzolasyon: Namespace'leri ve Network Policy'leri duvar gibi ör.\n2. Denetim: Kim ne yapıyor? Audit Log'larını mutlaka topla ve analiz et.\n3. Otomasyon: Manuel müdahaleyi bırak, altyapını kodla yönet (IaC) ve güvenlik taramalarını (Kube-bench, Kubescape) CI/CD hattına ekle.\n\nUnutma, Kubernetes karmaşıktır. Ve karmaşıklık, güvenliğin en büyük düşmanıdır. İşleri basit tut, yetkileri kısıtla ve her zaman en kötü senaryoya göre hazır ol.\n\nSistemlerini güvenli tut dostum, bir sonraki sızma testinde görüşmemek üzere!"