Kubernetes v1.36 حالا پشتیبانی از User Namespaces را به حالت GA رسانده است — یک قابلیت مهم و منتظرشده برای تیم‌هایی که روی runtimeهای کانتینری سطح پایین و تکنولوژی‌های rootless کار می‌کنند. 🐧🔒

این قابلیت صرفاً در لینوکس فعال است و به شما اجازه می‌دهد از جداسازی امنیتی «rootless» برای ورک‌لودهای Kubernetes استفاده کنید؛ یعنی فرایندها می‌توانند در ظرف کانتینر با UID 0 اجرا شوند اما از منظر میزبان به‌عنوان root کامل شناخته نشوند.

یکی از الگوهای کلیدی که این ویژگی ممکن می‌کند، توانایی اجرای workloadها با امتیازات مدیریتی لازم ولی محصور در user namespace است. با تنظیم hostUsers: false در Pod spec، قابلیت‌هایی مثل CAP_NET_ADMIN به صورت namespaced عمل می‌کنند — یعنی آن‌ها قدرت مدیریت منابع محلی کانتینر را می‌دهند بدون اینکه میزبان تحت‌تأثیر قرار بگیرد. این درها را برای موارد استفاده‌ای باز می‌کند که قبلاً برای انجام‌شان باید کانتینر کاملاً privileged اجرا می‌کردید. ✅

مسئله اصلی با UID 0 این است که یک پروسه داخل کانتینر که به‌عنوان root اجرا می‌شود، از نگاه کرنل همان root میزبان هم هست. اگر حمله‌ای منجر به فرار از کانتینر شود — مثلاً از طریق یک آسیب‌پذیری کرنل یا یک mount نادرست — آن مهاجم به‌عنوان root روی میزبان عمل خواهد کرد. بسیاری از مکانیسم‌های امنیتی وجود دارند، اما تا زمانی که هویت پروسه به‌صورت واقعی تغییر نکند، بخش‌هایی از دسترسی‌های root باقی می‌ماند.

مسیر رسیدن به GA صرفاً مربوط به API کبرنتیز نبود؛ باید کرنل هم «برای ما کار می‌کرد». یکی از بزرگ‌ترین موانع اولیه مالکیت فایل‌ها روی حجم‌ها بود: اگر UID کانتینر به رنج بالایی نگاشت می‌شد، kubelet مجبور بود به‌صورت بازگشتی همه فایل‌های volume را chown کند تا کانتینر بتواند بخواند/بنویسد؛ برای حجم‌های بزرگ این کار بسیار گران‌قیمت و مخرب برای زمان startup بود.

راه‌حل کلیدی، ID-mapped mounts بود (معرفی‌شده در Linux 5.12 و بعدتر کامل‌تر شد). به‌جای بازنویسی مالکیت فایل‌ها روی دیسک، کرنل آن‌ها را در زمان mount بازنگاشت می‌کند. وقتی یک حجم با User Namespaces فعال وارد Pod می‌شود، کرنل به‌طور شفاف UIDها و GIDها را ترجمه می‌کند: برای کانتینر فایل‌ها مالکیت UID 0 را دارند، اما روی دیسک مالکیت تغییری نکرده — بنابراین نیازی به chown نیست. این عملیات عملاً O(1) است، فوری و بسیار کارآمد. ⚡️

استفاده در Kubernetes v1.36 بسیار ساده است: کافی‌ست در specِ Pod یا PodTemplate مقدار hostUsers: false را تنظیم کنید. نیازی به تغییر در ایمیج‌ها یا پیکربندی پیچیده نیست؛ همان اینترفیسِ معرفی‌شده در فاز Alpha حفظ شده است. برای نمونه:

apiVersion: v1
kind: Pod
metadata:
  name: isolated-workload
spec:
  hostUsers: false
  containers:
  - name: app
    image: fedora:42
    securityContext:
      runAsUser: 0

چند نکته عملی برای تیم‌های DevOps / SRE:

• اطمینان حاصل کنید کرنلِ میزبان از ID-mapped mounts پشتیبانی می‌کند (معمولاً Linux 5.12+ یا backportهای مربوطه). 🧩
• بررسی کنید container runtime و CSI drivers/volume plugins شما از idmapped mounts یا نحوهٔ کار با owner mapping پشتیبانی کنند؛ در برخی پیاده‌سازی‌ها ممکن است نیاز به آپدیت یا تنظیمات اضافی باشد.🔎
• قبل از فعال‌سازی در تولید، روی کلاسترهای تستی و حجم‌های نمونه تجربه کنید تا اثرات روی زمان startup و دسترسی فایل را بسنجید.🧪
• همیشه مدل تهدید خود را بازبینی کنید: هرچند ویژگی کمک قابل‌توجهی به کاهش سطح دسترسی میزبان می‌کند، اما نباید به‌عنوان تنها لایهٔ دفاعی تلقی شود.

اگر می‌خواهید در توسعه یا تست User Namespaces مشارکت کنید یا بیشتر بدانید، دنبال documentation، KEP-127 و فعالیت‌های SIG Node باشید — این قابلیت نتیجهٔ سال‌ها کار مشترک بین تیم‌های کُرنل، رانتایم‌ها و SIG Node است. 🙏

اضافه‌بر این، کار روی این قابلیت بیش از سال‌ها طول کشید: اولین KEP حدود ده سال پیش باز شد و حدود ۶ سال است که توسعهٔ فعال ادامه داشته؛ تقدیر و تشکر از همهٔ مشارکت‌کنندگان، بازبین‌ها و زودپذیرندگان که در دوره‌های alpha و beta به تکامل طراحی کمک کردند.