Kubernetes cluster'ınızı sıkılaştırmak için tüm doğru adımları attınız. runAsNonRoot: true, readOnlyRootFilesystem: true gibi ayarlarla pod'larınızı kilitleyin. Ancak, kubectl debug node/my-node-name -it --image=ubuntu komutunu çalıştırdığınızda, saniyeler içinde host makinesinin root dosya sistemine tam erişime sahip bir shell elde edersiniz. Bu, container izolasyonunun anında çökmesi anlamına gelir. Peki bu nasıl oluyor ve nasıl engellenir?
kubectl debug node komutu, aslında Kubernetes tarafından tasarlanmış bir hata ayıklama aracıdır. Ancak, bu araç hostPID, hostNetwork gibi ayrıcalıklı ayarlarla çalışan bir debug pod'u oluşturur. Normalde pod seviyesinde uygulanan kısıtlamaları aşar ve host'un kök dizinine erişir. Eğer bir saldırgan, yeterli izinlere sahip bir servis hesabı veya kullanıcı kimlik bilgisi ele geçirirse, container izolasyonunuz bir anda yok olur. İşte bu nedenle, bu komutu tamamen kapatmak kritik öneme sahiptir.
İlk savunma katmanı: Namespace Seviyesinde Pod Security Admission (PSA). kubectl debug node, helper pod'u aktif namespace'inizde başlatır. Eğer namespace, Restricted güvenlik standardını zorluyorsa, API sunucusu debug pod'unu reddeder. Bunu uygulamak için: kubectl label --overwrite ns default pod-security.kubernetes.io/enforce=restricted. Bu işe yarar çünkü debug pod'u hostPID: true ve hostPath mount gerektirir; Restricted profili ise bunları yasaklar.
İkinci ve daha sağlam katman: Cluster genelinde otomasyon. Manuel namespace etiketlemesi insan hatasına açıktır. Bunun yerine, her yeni namespace için Restricted profilini varsayılan yapacak bir Admission Configuration ayarlayın. Bir admission-config.yaml dosyası oluşturun ve API sunucunuza ekleyin. Örneğin, k0s kullanıyorsanız, /etc/k0s/k0s.yaml dosyasına spec.api.extraArgs.admission-control-config-file parametresini ekleyin. Bu sayede sistem pod'ları hariç tüm namespace'ler sıkı güvenlik kurallarına tabi olur.
Detaylar ve Etkileri
Üçüncü katman: RBAC ile yapısal düzeltme. kubectl debug node, nodes/proxy ve pods/ephemeralcontainers gibi API alt kaynaklarına erişim gerektirir. ClusterRole'larınızı denetleyin ve bu izinlerin sadece admin kullanıcılara verildiğinden emin olun. Ayrıca, acil durumlar için bir Break-Glass Namespace oluşturun. Bu namespace'e privileged etiketi vererek, normal kullanımda debug'ı bloke ederken, acil bakım için denetimli bir arka kapı bırakabilirsiniz.
Uzmanların Görüşleri
Tüm bunları test etmek için yerel bir k0s laboratuvarı kurabilirsiniz. Docker container içinde hafif bir k0s cluster'ı başlatın: docker run -d --name k0s-lab --privileged -v /var/lib/k0s -p 6443:6443 docker.io/k0sproject/k0s:v1.36.1-k0s.0 k0s controller --enable-worker --ignore-pre-flight-checks. Ardından Restricted profilini uygulayın ve kubectl debug node komutunu deneyin. API sunucusu, hatayla karşılaşacak ve güvenlik önleminizin çalıştığını göreceksiniz. Unutmayın, güvenlik katmanlı bir yaklaşım gerektirir; bu üç adım cluster'ınızı büyük ölçüde koruyacaktır.
Kaynak: dev.to
