Kubernetes v1.37’de Rootless Mod Beta Aşamasına Geldi

⏱️ 4 dk okuma📅 5 Eylül 2026

Kubernetes v1.37 ile KubeletInUserNamespace özellik kapısı beta aşamasına yükseldi. Bu özellik, kubelet, CRI ve OCI çalışma zamanları, CNI eklentileri ile kube-proxy gibi düğüm bileşenlerinin ana makinede root olmayan bir kullanıcıyla çalıştırılmasını sağlıyor. Bu yaklaşım Kubernetes ekosisteminde “rootless mode” olarak da anılıyor.

Rootless Kubernetes ne sağlıyor?

Rootless modda düğüm bileşenleri bir Linux kullanıcı ad alanında çalışıyor. Ana makinedeki root olmayan kullanıcı, bu ad alanında sahte root kimliğiyle temsil ediliyor. Kimliğin yetkileri ad alanının içiyle sınırlı kalıyor.

Sahte root kimliği, volume bağlama, cgroup oluşturma ve pod’ların ağ ad alanlarını yapılandırma gibi düğüm bileşenlerinin görevlerinin çoğu için yeterli olabiliyor. Ancak bazı CNI ve CSI sürücüleriyle uyumluluk sorunlarına yol açabilecek kısıtlamalar var.

Kullanıcı ad alanını Kubernetes kendisi oluşturmuyor; ad alanını Kubernetes dışında hazırlamak gerekiyor. Örneğin rootless Docker, Kubernetes’in çalışacağı kullanıcı ad alanını hazırlamak için kullanılabiliyor.

Neden düğüm bileşenleri root olmadan çalıştırılmalı?

Düğüm bileşenleri geçmişte, bir konteynerden çıkış gerçekleştiğinde ana makinedeki tam root yetkilerinin ele geçirilmesine yol açabilecek güvenlik açıklarıyla karşılaştı. Kaynakta şu açıklar örnek veriliyor:

CVE-2022-0811: CRI-O, kernel.core_pattern gibi keyfi sysctl değerlerini ayarlamak üzere kandırılabiliyor ve bu da ana makinede root olarak keyfi kod çalıştırılmasına yol açabiliyordu.
CVE-2023-27561: runc, bir volume bağlama yarış durumu üzerinden konteynerin maskelenmiş yollarını aşabiliyor ve ana makinenin procfs dosyalarını açığa çıkarabiliyordu. Bu açık, CVE-2019-19921’in gerilemesi olarak tanımlanıyor.
CVE-2024-10220: Kubelet, gitRepo volume’ları üzerinden root yetkisiyle keyfi komut çalıştırmaya zorlanabiliyordu. gitRepo volume’larıyla ilgili 2018 tarihli CVE-2018-11235 de benzer bir soruna işaret ediyor.
CVE-2025-31133: runc, saldırganın kontrolündeki yolları bind mount olarak bağlamaya ve /proc/sysrq-trigger ile /proc/sys/kernel/core_pattern gibi ana makine procfs dosyalarına yazmaya zorlanabiliyordu.
CVE-2026-53488: containerd, konteyner imajındaki hazırlanmış etiketler aracılığıyla ana makinede keyfi komut çalıştırmaya zorlanabiliyordu.

Düğüm bileşenlerini kullanıcı ad alanında çalıştırmak, bu tür açıkların verebileceği olası zararı root olmayan kullanıcının hesabıyla sınırlamayı amaçlıyor. Ancak bu model, saldırganın çekirdeği, önyükleyiciyi veya firmware’i değiştirerek izlerini gizlemesini engellemiyor. Kullanıcı ad alanları, doğrudan Linux çekirdeğindeki güvenlik açıklarını azaltmak için de etkili bir çözüm olarak görülmemeli.

Bu nedenle rootless mod, geleneksel sertleştirme önlemlerinin yerini almıyor. Kaynak, konteynerlerin gereksiz sistem çağrılarını yapmasını önlemek için seccomp gibi yöntemlerle birlikte kullanılmasını öneriyor.

Hangi kullanım senaryoları öne çıkıyor?

Üretim kümeleri: Olası konteynerden çıkış açıklarının etkisini azaltmak.
Paylaşımlı makineler: HPC ortamları gibi sistemlerde kullanıcıların makine yöneticisinden root yetkisi istemeden Kubernetes çalıştırabilmesi ve diğer kullanıcıların ortamlarını yanlışlıkla bozmaması.
Dizüstü bilgisayarlar: Yerel bir kümenin VPN’ler tarafından kullanılan ana makine iptables kuralları gibi sistem ayarlarını yanlışlıkla değiştirmesini önlemek.
AI sandbox ortamları: Bir AI kodlama aracını ve test Kubernetes kümesini özel bir yerel kullanıcı hesabında çalıştırarak, internet üzerindeki kötü amaçlı bilgilerle yönlendirilen aracın ana makineye zarar verme riskini sınırlamak.
Kubernetes içinde Kubernetes: İç içe kümeyi hostUsers: false kullanan kullanıcı ad alanlı bir pod içinde çalıştırmak. Bu, iş yüklerini yalnızca Kubernetes API ad alanlarıyla ayırmaya göre daha güçlü bir izolasyon sağlayabiliyor.
Önyükleme: Cluster API gibi araçlarla gerçek bir kümeyi hazırlamadan önce geçici ve ayrıcalıksız bir küme kullanmak.

Beta aşamasında neler değişti?

KubeletInUserNamespace özellik kapısı artık varsayılan olarak etkin. Ancak bu, kubelet’i kendiliğinden bir kullanıcı ad alanına taşımıyor. Mevcut rootful kümelerin çalışma biçimi yalnızca özellik kapısının etkinleşmesiyle değişmiyor.

kubectl get nodes -o yaml çıktısı, düğümün kullanıcı ad alanında çalışıp çalışmadığını runningInUserNamespace özelliğiyle bildiriyor. Küme yöneticisi bu bilgiyi düğüm etiketleri veya taint’ler oluşturmak için kullanabilir. Böylece gerçek root yetkisi gerektiren iş yükleri, örneğin bazı CNI eklenti yükleyicileri, rootless düğümlere planlanmayabilir.

Kubernetes’in kendi CI/CD testlerindeki düğüm uyumluluk uçtan uca testleri artık rootless bir kümede de çalışıyor. Bu test kümesi ci-kubernetes-e2e-kind-rootless adıyla belirtiliyor.

Geçişi destekleyen başka gelişmeler de var. Linux çekirdeği v6.3, idmapped tmpfs desteği ekledi. Kubernetes v1.33, UserNamespacesSupport özellik kapısını varsayılan olarak etkinleştirerek hostUsers: false kullanan kullanıcı ad alanlı pod’ların ek yapılandırma olmadan oluşturulmasına izin verdi. containerd v2.1 ise yazılabilir cgroup desteği ekledi.

Bu gelişmelerle KubeletInUserNamespace kullanan bir Kubernetes kümesi, hostUsers: false ve UserNamespacesSupport ile Kubernetes pod’larının içinde de çalıştırılabiliyor.

Rootless Kubernetes nasıl kullanılabilir?

kind, rootless Docker, rootless nerdctl veya rootless Podman içinde Kubernetes kümesi çalıştırmak için en kolay seçeneklerden biri. Docker örneği şöyle:

dockerd-rootless-setuptool.sh install
kind create cluster

Makinenin yapılandırmasına göre systemd, çekirdek modülleri ve sysctl ayarları için ek yapılandırma gerekebilir.

minikube da rootless Docker veya rootless Podman ile Kubernetes çalıştırmayı destekliyor:

dockerd-rootless-setuptool.sh install
minikube start --driver=docker

Usernetes, makalenin yazarı tarafından sürdürülen üçüncü taraf bir rootless Kubernetes dağıtımı olarak tanımlanıyor. Proje 2018’de başladı ve KubeletInUserNamespace özellik kapısının ilk kaynaklarından biri oldu. kind ve minikube’dan farklı olarak Usernetes, rootless Docker, Podman veya nerdctl kullanan birden fazla düğüm oluşturabiliyor. Bu düğümler Flannel CNI eklentisi üzerinden VXLAN ile bağlanabiliyor. Projenin Kubernetes-in-Kubernetes modu da deneysel olarak destekleniyor.

Bir CNCF Sandbox projesi olan k3s de rootless modu destekliyor. kind, minikube ve Usernetes’in mevcut neslinden farklı olarak rootless k3s, harici bir rootless Docker çalışma zamanına dayanmıyor.

GA yol haritası ve katkı seçenekleri

Kubernetes projesi, geri bildirim ve benimsenme durumuna göre özelliği gelecekteki bir sürümde Genel Kullanıma Açık (GA) aşamasına taşımayı planlıyor. Proje, bu özellikle Kubernetes-in-Kubernetes kullanımını kolaylaştırabilecek bazı Kubernetes Enhancement Proposal çalışmalarını da değerlendiriyor. Bunlar arasında ayrıcalıksız konteynerler için yazılabilir cgroup’ları etkinleştirmeyi amaçlayan KEP-5474 ve cgroup ad alanlarının ayrıştırılıp ayrıştırılmayacağını belirlemeye yönelik KEP-5714 bulunuyor.

Katkı sunmak isteyenler Node Special Interest Group’a katılabilir. Özellikle özellik hakkında geri bildirim paylaşmak isteyenler Kubernetes deposunda issue açabilir veya Kubernetes’in herkese açık Slack kanalını kullanabilir.

Kaynaklar ve İleri Okuma

Bu yazı yapay zeka (büyük dil modelleri) ile hazırlanmış, insan editör tarafından incelenmiştir. İçerik üretim sürecimiz.

Aşkın KILIÇYazar

20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102