Kubernetes v1.33 bật mặc định user namespaces để tăng cường cách ly

Trong một bài đăng trên Kubernetes Blog vào tháng 4 năm 2025, các nhà bảo trì đã thông báo rằng Kubernetes v1.33 bật hỗ trợ Linux user namespaces theo mặc định. Thay đổi này cho phép các pod chọn tham gia cơ chế cách ly mạnh mẽ hơn mà không cần cờ tính năng (feature flags), miễn là hạ tầng cơ bản đáp ứng các yêu cầu cụ thể về kernel và runtime.

Chuyện gì đã xảy ra

Trước phiên bản này, việc sử dụng user namespaces trong Kubernetes đòi hỏi phải bật các feature gates tường minh và thực hiện nhiều bước cấu hình phức tạp. Với phiên bản 1.33, tính năng này đã ổn định và được kích hoạt theo mặc định. Khi đáp ứng đủ các yêu cầu của stack, người dùng chỉ cần chọn tham gia thông qua các đặc tả pod. Sự thay đổi này đánh dấu một bước tiến quan trọng hướng tới việc điều phối container an toàn theo mặc định, giảm bớt những rào cản khi triển khai các mô hình bảo mật nguyên tắc ít đặc quyền nhất (least-privilege).

Thông báo làm rõ rằng đây là tính năng chỉ dành cho Linux. Nó phân biệt Linux user namespaces, vốn cô lập các định danh người dùng ở cấp độ kernel, với Kubernetes namespaces, vốn là các cụm logic cho tài nguyên. Bản cập nhật nhằm giảm thiểu rủi ro liên quan đến việc thoát khỏi container (container escapes) bằng cách đảm bảo rằng các tiến trình chạy với quyền root bên trong container không giữ đặc quyền root trên node host.

Cách thức hoạt động

Linux user namespaces cô lập các User ID (UID) và Group ID (GID) của các tiến trình trong container khỏi các UID/GID trên hệ thống host. Khi một pod sử dụng user namespace, các UID và GID bên trong container sẽ được ánh xạ sang các định danh khác, không có đặc quyền trên host. Ví dụ, một tiến trình chạy với UID 0 (root) bên trong container có thể được ánh xạ sang UID 100000 trên host. Cơ chế ánh xạ này đảm bảo rằng ngay cả khi một tiến trình container thoát khỏi ranh giới của nó, tiến trình đó cũng không có quyền sửa đổi các file trên host hoặc tương tác với các tiến trình khác trên host với tư cách là người dùng có đặc quyền.

Cơ chế này phụ thuộc rất nhiều vào "idmap mounts", một tính năng của Linux kernel áp dụng các ánh xạ UID/GID khi truy cập các hệ thống file đã mount. Idmap mounts cho phép mỗi pod sử dụng các UID riêng biệt trên host mà không cần thay đổi thủ công quyền sở hữu file (chown) trên các volume. Điều này đơn giản hóa việc quản lý volume và cho phép các tính năng như chia sẻ volume giữa các pod có các ánh xạ người dùng khác nhau. Tuy nhiên, các hệ thống file được sử dụng cho volume phải hỗ trợ idmap mounts. Hầu hết các hệ thống file phổ biến đều được hỗ trợ, nhưng NFS đáng chú ý là chưa nằm trong danh sách hỗ trợ hiện tại.

Chi tiết chính

• Cơ chế chọn tham gia: Người dùng bật tính năng này bằng cách đặt hostUsers: false trong đặc tả pod.
• Yêu cầu kernel: Khuyến nghị sử dụng Linux kernel phiên bản 6.3 trở lên để hỗ trợ tmpfs cho secrets và config maps. Kernel 5.19 là mức tối thiểu để hỗ trợ overlayfs.
• Tương thích runtime: Yêu cầu Containerd phiên bản 2.0 trở lên. CRI-O hoạt động sẵn sàng (out of the box). Các runtime khác, bao gồm cri-dockerd, hiện chưa hỗ trợ tính năng này với Kubernetes.
• Lợi ích bảo mật: Ngăn chặn sự di chuyển ngang (lateral movement) giữa các container và đảm bảo rằng các capabilities được cấp trong namespace không còn hiệu lực trên host.
• Hạn chế: Các ứng dụng yêu cầu đặc quyền trực tiếp trên host, chẳng hạn như nạp module kernel, không thể sử dụng user namespaces. Volume NFS không được hỗ trợ với idmap mounts.

Tại sao điều này quan trọng

Đối với các kỹ sư phần mềm và đội ngũ nền tảng, bản cập nhật này giải quyết một vấn đề bảo mật lâu đời: chạy ứng dụng với quyền root bên trong container vì lý do tương thích trong khi cố gắng giảm thiểu rủi ro trên host. Theo truyền thống, việc chạy dưới dạng non-root đòi hỏi phải tái cấu trúc ứng dụng đáng kể hoặc các giải pháp tùy chỉnh phức tạp để quản lý quyền file. User namespaces cho phép các đội ngũ chạy ứng dụng với quyền root nội bộ mà không cấp đặc quyền cấp host, tách biệt hiệu quả logic ứng dụng khỏi các ràng buộc bảo mật hạ tầng.

Việc bật mặc định cũng củng cố khả năng phòng thủ trước các lỗ hổng thoát container. Các CVE phổ biến, chẳng hạn như CVE-2024-21626 và CVE-2022-0492, được giảm thiểu vì các tiến trình thoát ra chỉ giữ lại danh tính host không có đặc quyền. Điều này làm giảm bề mặt tấn công cho sự di chuyển ngang, nơi một container bị xâm nhập có thể truy cập các file hoặc tiến trình thuộc về các container khác trên cùng một node. Bằng cách đảm bảo các UID host duy nhất cho mỗi pod, kubelet thực thi sự cách ly mà trước đây khó đạt được một cách nhất quán.

Những gì bạn có thể làm

• Xác minh rằng các node của bạn đang chạy Linux kernel 6.3 trở lên để đảm bảo tương thích đầy đủ với các volume tmpfs.
• Nâng cấp các container runtime lên containerd 2.0+ hoặc đảm bảo bạn đang sử dụng phiên bản CRI-O tương thích.
• Kiểm thử các workload hiện có bằng cách thêm hostUsers: false vào các đặc tả pod trong môi trường staging để xác định bất kỳ vấn đề nào liên quan đến quyền hạn.
• Xem xét các loại volume được sử dụng trong cụm của bạn; tránh sử dụng NFS cho các pod chọn tham gia user namespaces cho đến khi hỗ trợ được bổ sung.
• Tham khảo trang man page của mount_setattr để kiểm tra hỗ trợ idmap mount cho các hệ thống file cụ thể nếu bạn đang sử dụng các kernel cũ hơn.
• Đánh giá các ứng dụng yêu cầu đặc quyền cấp host, chẳng hạn như trình nạp module kernel, vì chúng sẽ không hoạt động khi user namespaces được bật.