Cloud có thể chia ứng dụng thành hàng nghìn container: Nhưng trên mỗi node, chúng vẫn đứng trên cùng một Linux kernel

Kubernetes có thể chia một hệ thống thành hàng nghìn container, mỗi container có filesystem, process tree, network namespace và resource limit riêng. Nhìn từ bên trong, chúng giống những máy nhỏ độc lập. Nhưng ở tầng thấp hơn có một chi tiết quan trọng: những container nằm trên cùng một Linux node vẫn gọi vào cùng một kernel.

Tháng 7/2026, một lỗ hổng trong chính tầng dùng chung đó cho thấy hậu quả của thiết kế này. Red Hat mô tả CVE-2026-53362, còn được gọi là ipv6_frag_escape, là lỗi privilege escalation và container escape trong subsystem IPv6 của Linux kernel. Trong cấu hình RHEL 10 chịu ảnh hưởng, một process không đặc quyền bên trong container có thể đi qua ranh giới container, vượt qua SELinux và giành quyền root trên host.

Đây không phải bằng chứng rằng container “không có isolation”. Ngược lại, nó cho thấy chính xác isolation của container nằm ở đâu: phần lớn ranh giới được kernel dựng lên. Khi bug nằm ngay trong kernel, nhiều lớp tách biệt phía trên có thể không còn là ranh giới cuối cùng.

Container không phải một VM nhỏ

Sự nhẹ và nhanh của container đến từ việc nó không boot một operating system hoàn chỉnh cho mỗi workload. Docker mô tả nhiều container trên cùng máy như các process user-space được cô lập nhưng cùng chia sẻ OS kernel. Red Hat cũng định nghĩa Linux container là một hoặc nhiều process được cô lập khỏi phần còn lại của hệ thống bằng các primitive của Linux.

Kernel dùng namespaces để tạo những “góc nhìn” khác nhau về process ID, network, mount point, user và các tài nguyên khác. cgroups giới hạn CPU, memory và resource consumption. Capabilities chia quyền root thành các quyền nhỏ hơn; seccomp có thể chặn syscall; SELinux hoặc AppArmor thêm policy kiểm soát truy cập.

Những lớp đó khiến process trong container A thông thường không nhìn thấy process của container B hay filesystem thật của host. Nhưng khi một application gọi send(), mở file, xin memory hoặc tạo network object, request cuối cùng vẫn đi vào kernel của node.

VM đặt ranh giới ở vị trí khác. Mỗi VM thông thường có guest kernel riêng, còn hypervisor nằm giữa guest và hardware. Vì thế một bug trong guest Linux kernel trước hết phá ranh giới bên trong VM đó; muốn đi tiếp tới host còn cần một lỗ hổng ở lớp virtualization. Container đổi một phần isolation đó lấy mật độ cao, startup nhanh và overhead thấp hơn.

CVE-2026-53362 bắt đầu từ một phép tính sai trong IPv6

Lỗi này nằm trong hàm __ip6_append_data(), thuộc đường xử lý mà Linux dùng để xây dựng packet IPv6. Theo Red Hat, một phép tính chiều dài không chính xác trong quá trình fragmentation có thể dẫn tới out-of-bounds write vào cấu trúc skb_shared_info của kernel.

Ở mức độ an toàn để mô tả, điều quan trọng là corruption này xảy ra trong memory của kernel chứ không còn bị giới hạn trong address space của process bên trong container. Proof-of-concept công khai cho thấy lỗi có thể được nối thành primitive đọc/ghi kernel memory, sau đó thay đổi credential và thoát khỏi namespace để lấy quyền root trên host.

PoC không hoạt động trên mọi Linux machine chỉ vì máy đó dùng container. Phiên bản công khai được xây cho CentOS/RHEL 10 và có một số điều kiện cụ thể về kernel configuration và phần cứng. Red Hat cũng nói việc khai thác cần khả năng tạo network namespace; cấu hình RHEL 10 mặc định cho phép một unprivileged user đạt điều đó thông qua user namespace.

Đây là lý do phạm vi ảnh hưởng phải được đọc theo distro advisory chứ không phải suy từ headline. Red Hat liệt kê RHEL 10 là sản phẩm trực tiếp chịu ảnh hưởng và đã phát hành fix cho các sản phẩm liên quan. OpenShift Container Platform của hãng không chịu lỗ hổng này trong cấu hình được Red Hat hỗ trợ vì các phiên bản đang xét dùng RHEL 9, không nằm trong phạm vi đó.

Một container bị chiếm không đồng nghĩa toàn bộ cloud bị chiếm

“Container escape” dễ tạo cảm giác attacker từ một pod có thể lập tức nắm cả cluster. Thực tế blast radius phụ thuộc kiến trúc.

Nếu nhiều pod chia sẻ một Kubernetes node có kernel dễ tổn thương và attacker đạt được host root, ranh giới giữa các workload trên node đó bị đe dọa nghiêm trọng. Host root có thể tiếp cận runtime, filesystem, credential hoặc network material mà node đang nắm giữ, tùy cấu hình.

Nhưng một cluster thường gồm nhiều node. Việc có root trên một node không tự động tương đương có root trên mọi node hoặc trên control plane. Cloud provider cũng thường đặt Linux nodes bên trong VM, nên một kernel escape từ container có thể vẫn bị chặn tại ranh giới hypervisor của VM. Để đi từ guest root tới hạ tầng vật lý của provider cần một đường tấn công khác.

Điều này vẫn không làm nhẹ vấn đề. Trong một CI runner chạy code không tin cậy, một multi-tenant platform hoặc node chứa nhiều service của cùng doanh nghiệp, việc biến một workload compromise thành host compromise đã là một bước leo thang rất lớn.

Image scanner có thể sạch trong khi kernel bên dưới vẫn có lỗ hổng

Container security thường tập trung mạnh vào image: package nào cũ, thư viện nào có CVE, base image nào cần rebuild. Việc đó cần thiết nhưng chỉ bao phủ software được đóng gói trong image.

Linux kernel của host thường không nằm trong container image. Một Alpine, Ubuntu hay distroless image đều có thể chạy trên cùng kernel của node. Vì vậy rebuild hàng trăm image không sửa được một lỗi như CVE-2026-53362; patch phải đi vào kernel package của node hoặc image hệ điều hành dùng để boot node.

Đây là một khác biệt vận hành quan trọng trong cloud-native security. Application team có thể sở hữu Dockerfile, dependency và manifest, trong khi platform team sở hữu node image, kernel patch cadence và lịch reboot. Nếu vulnerability management chỉ nhìn SBOM của application image, một phần attack surface dùng chung sẽ bị bỏ sót.

User namespace giúp giảm nhiều loại breakout, nhưng không biến kernel bug thành vô hại

Tháng 9/2026, Kubernetes 1.37 đưa KubeletInUserNamespace — rootless mode cho các thành phần node — lên beta. Kubernetes giải thích rằng chạy kubelet, runtime và các thành phần liên quan bên trong user namespace có thể giới hạn thiệt hại của nhiều lỗ hổng ở container runtime: nếu process thoát ra, nó vẫn chỉ là non-root user trên host.

Nhưng chính tài liệu này cũng chỉ ra giới hạn: user namespaces không phải mitigation chung cho vulnerability nằm trong kernel itself. Một kernel memory corruption có thể xảy ra bên dưới lớp mapping UID/GID mà user namespace tạo ra.

Với CVE-2026-53362, câu chuyện còn tinh tế hơn. Việc unprivileged user có thể tạo user namespace lại là một phần điều kiện giúp public exploit chạm tới network namespace cần thiết trên RHEL 10. Red Hat vì thế đưa việc hạn chế unprivileged user namespaces ra như workaround tạm thời nếu hệ thống không cần chức năng đó, nhưng nhấn mạnh rằng giải pháp đúng vẫn là cập nhật kernel. Tắt user namespace có thể làm hỏng rootless Podman và một số sandbox, nên đây không phải switch nên tắt bừa trên mọi máy.

Seccomp và capability vẫn quan trọng vì chúng giảm phần kernel mà workload có thể chạm tới

Một kernel chung tạo ra attack surface chung, nhưng container không nhất thiết được phép gọi mọi chức năng kernel. Đây là nơi hardening vẫn có giá trị.

Kubernetes khuyến nghị tránh privileged container, bỏ capability không cần thiết và chạy workload dưới non-root user khi có thể. Seccomp có thể giảm tập syscall mà process được phép gọi. SELinux/AppArmor tiếp tục hạn chế file và object mà process có thể truy cập. Những biện pháp này không thay thế patch, nhưng chúng có thể loại bỏ nhiều đường tới bug trước khi exploit có cơ hội bắt đầu.

Quan trọng hơn, security team cần biết workload nào thực sự cần đặc quyền. Một database bình thường không nên chạy với CAP_SYS_ADMIN; một web API không cần host network hay host PID namespace. Mỗi permission bị loại bỏ là một phần kernel interface mà attacker khó tận dụng hơn sau khi application bị compromise.

Vì sao microVM và sandbox tách kernel đang quay trở lại?

Có một cách khác để thay đổi ranh giới: không cho workload không tin cậy dùng trực tiếp kernel của host.

Những hệ thống dựa trên microVM đặt một kernel riêng quanh workload hoặc sandbox. Docker hiện cũng dùng mô hình này cho AI Sandboxes: mỗi sandbox chạy trong một lightweight microVM với Linux kernel riêng, thay vì chia sẻ kernel của host như container thông thường.

Đổi lại, isolation mạnh hơn đi cùng thêm memory, startup cost và operational complexity. Vì thế không có lý do để biến mọi microservice nội bộ thành một VM riêng. Nhưng với workload thực thi code của khách hàng, CI job từ repository không tin cậy, notebook đa tenant hay AI agent tự chạy code, ranh giới kernel riêng có thể đáng chi phí hơn.

Patch kernel trong cloud-native là bài toán node lifecycle

Fix upstream cho lỗi fragmentation đã được đưa vào các stable kernel, và các distro lớn liên quan đã phát hành bản vá. Nhưng việc package tồn tại trong repository chưa có nghĩa một cluster đã an toàn. Kernel mới thường chỉ có hiệu lực sau khi node boot vào phiên bản đã vá.

Ở quy mô Kubernetes, quy trình hợp lý thường là tạo node image mới, thêm node đã vá vào cluster, drain workload khỏi node cũ rồi thay thế chúng theo từng đợt. Cách này phù hợp với nguyên tắc immutable infrastructure hơn là SSH vào từng server và hy vọng tất cả reboot đúng phiên bản.

Đội vận hành cũng nên kiểm tra kernel thật đang chạy, không chỉ version của package đã tải xuống. Với distro có backport security patch, số version upstream cũng không đủ để kết luận; advisory của vendor mới là nguồn xác nhận đúng cho build cụ thể.

Container scale được vì kernel được chia sẻ — và đó cũng là ranh giới phải bảo vệ

CVE-2026-53362 không phải lý do để quay lưng với container. Shared kernel chính là một trong những lý do container có thể được khởi động nhanh, đóng gói nhỏ và chạy với mật độ mà VM truyền thống khó đạt được.

Nhưng cùng một đặc tính tạo hiệu quả cũng tạo một lớp rủi ro khác với VM. Một cluster có thể có hàng nghìn pod, nhưng mỗi pod không mang theo hàng nghìn kernel riêng. Chúng được gom lên các node, và các workload trên cùng node phụ thuộc vào việc kernel đó thực thi đúng ranh giới namespace, permission và memory safety.

Vì vậy, security của cloud-native stack không kết thúc ở việc quét image và vá npm package. Cần theo dõi cả kernel CVE, runtime, node OS, capability, seccomp và loại isolation phù hợp với mức độ tin cậy của workload. Container làm application nhỏ đi; nó không làm kernel bên dưới biến mất.