Kubernetes Güvenliğini Artırmak: `kubectl debug node` Tehlikesine Karşı Nasıl Önlem Alınır?

kubectl debug node komutunu çalıştırdığınızda, Kubernetes otomatik olarak konak makineye tam erişim sağlayan bir "hata ayıklama" pod’u oluşturur. Bu pod, standart container izolasyonunu bypass ederek, host’un PID, ağ ve IPC ad alanlarına doğrudan bağlanır ve kök dizinini (/) bağlar.

Bu durum, saldırganların ele geçirdiği bir servis hesabı veya kullanıcı kimlik bilgileriyle, tüm konteyner güvenlik duvarını anında devre dışı bırakmalarına olanak tanır. Peki bu açık nasıl kapatılır? Üç farklı savunma katmanıyla Kubernetes cluster’ınızı nasıl koruyabileceğinize dair adım adım rehber sunuyoruz — ve tüm bunları yerel bir k0s lab’ında test etmek için nasıl bir Docker ortamı kurabileceğinizi gösteriyoruz.

1. Hızlı Çözüm: Namespace Düzeyinde Pod Güvenlik Denetimi (PSA)

kubectl debug node komutu, yardımcı pod’unu çalıştırdığı namespace’e bağlı olarak bir dizi kısıtlamaya tabi olur. Eğer namespace’iniz Kubernetes’in varsayılan Baseline veya Restricted güvenlik profillerinden birini uyguluyorsa, API sunucusu debugger pod’unu doğrudan reddedecektir.

Varsayılan ad alanı (default) için bu korumayı etkinleştirmek oldukça basittir:

kubectl label --overwrite ns default pod-security.kubernetes.io/enforce=restricted

Bu yöntemin çalışma mantığı basittir: Debug pod’u hostPID: true ve hostPath bağlamaları gerektirir. Restricted profili ise bu tür erişimleri yasaklar, böylece pod bile oluşmadan önce API sunucusu talebi reddeder.

---

2. En Sağlam Yol: Küme Genelinde Otomasyon

Namespace etiketlerini elle yönetmek, insan hatasına açık bir alandır. Bunun yerine, tüm yeni namespace’ler için Restricted profilini zorunlu kılan bir küme genelinde Kabul Denetimi yapılandırması oluşturabilirsiniz.

Öncelikle, admission-config.yaml adlı bir yapılandırma dosyası oluşturun:

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: PodSecurity
    configuration:
      apiVersion: pod-security.admission.config.k8s.io/v1
      kind: PodSecurityConfiguration
      defaults:
        enforce: "restricted"
        enforce-version: "latest"
      exemptions:
        namespaces: ["kube-system", "kube-public", "k0s-system"]

Önemli not: Sistem pod’larının konak erişimine ihtiyacı vardır. Eğer k0s kullanıyorsanız, bu yapılandırma dosyasını API sunucusuna doğrudan aktarabilirsiniz. Bunu yapmak için /etc/k0s/k0s.yaml dosyasına aşağıdaki satırı ekleyin:

spec:
  api:
    extraArgs:
      admission-control-config-file: /etc/k0s/admission-config.yaml

---

3. Yapısal Çözüm: RBAC Yetkilerini Sıkılaştırma

kubectl debug node komutu, API’nin belirli alt kaynaklarına erişim gerektirir. Bu nedenle, ClusterRoles yetkilerinizi denetleyerek aşağıdaki erişimlerin engellendiğinden emin olun:

• nodes/proxy (düğüm hata ayıklama için gerekli)
• pods/ephemeralcontainers (pod düzeyinde hata ayıklama için kullanılır)

Bu adımları uyguladığınızda, hem kullanıcıların hem de servis hesaplarının node düzeyinde hata ayıklama işlemlerini gerçekleştirmesi neredeyse imkansız hale gelir.

---

Yerel Olarak Test Etmek: k0s Docker Oyun Alanı

Üretim cluster’ınızı riske atmadan bu güvenlik açıklarını yerinde test etmek için, Docker içinde çalışan hafif bir k0s cluster’ı kurabilirsiniz. (Not: macOS veya Windows üzerinde Docker Desktop kullanıyorsanız, kernel kısıtlamalarını bypass etmek için özel bir bayrak geçmeniz gerekebilir.)

Adım 1: Container’ı Başlatın

docker run -d --name k0s-lab \
  --hostname 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

Adım 2: Yerel kubectl Bağlantısını Kurun

API sunucusunun yaklaşık 15 saniye içinde hazır hale gelmesini bekleyin, ardından kubeconfig dosyasını alın:

docker exec k0s-lab k0s kubeconfig admin > ~/.kube/k0s-lab.config
export KUBECONFIG=~/.kube/k0s-lab.config

# Kontrol edin!
kubectl get nodes

Adım 3: Güvenlik Açığını Tetikleyin

Öncelikle, default namespace’ine Restricted güvenlik profilini uygulayın:

kubectl label --overwrite ns default pod-security.kubernetes.io/enforce=restricted

Ardından, hata ayıklama komutunu çalıştırarak cluster’ınızın güvenlik duvarını test edin:

kubectl debug node/k0s-lab -it --image=ubuntu

Sonuç: API sunucusu, kök erişimli bir terminal yerine aşağıdaki gibi bir reddetme mesajı döndürecektir:

Error from server (Forbidden): pods "node-debugger-..." is forbidden: violates PodSecurity "restricted:latest": hostNetwork: true, hostPID: true...

Artık oyun alanınız güvenli!

---

Acil Durumlar için "Break-Glass" Çözümü

Eğer cluster’ınızı o kadar sıkı bir şekilde kilitlediniz ki, node hata ayıklama işlemleri tamamen engellenmiş durumdaysa, gerçek bir acil durumda nasıl müdahale edeceksiniz?

En iyi uygulama, özel bir Break-Glass namespace tasarlamaktır:

• break-glass adında yeni bir namespace oluşturun:

kubectl create ns break-glass

• Bu namespace’i privileged olarak etiketleyin:

kubectl label ns break-glass pod-security.kubernetes.io/enforce=privileged

• Artık node hata ayıklama işlemini yalnızca bu namespace üzerinden gerçekleştirebilirsiniz:

kubectl debug node/k0s-lab -it --image=ubuntu -n break-glass

Bu sayede, günlük operasyonlarınızda oluşabilecek kazara erişimler engellenirken, yalnızca kasıtlı ve denetlenebilir acil durumlar için kontrollü bir arka kapı açık kalır. Tüm eylemler ayrıca kayıt altına alınır, böylece güvenlik denetimlerinde izlenebilir.

Cluster’larınızda konak düzeyindeki güvenliği nasıl yönetiyorsunuz? Deneyimlerinizi ve önerilerinizi yorumlarda paylaşın! 🛡️