Tại Sao Các Container Không Nên Chạy Dưới Quyền Root Theo Mặc Định?

Chạy container dưới quyền root là một trong những cấu hình sai — và nguy hiểm nhất — trong các môi trường production. Nó im lặng mở rộng bề mặt tấn công của mọi khối lượng công việc, và hầu hết các nhóm không nhận ra điều này cho đến khi một sự cố buộc phải xử lý.

"Chạy Dưới Quyền Root" Thực Sự Có Ý Nghĩa Gì

Theo mặc định, nhiều hình ảnh container (đặc biệt là những hình ảnh tối thiểu hoặc cũ) thực thi quy trình chính của chúng dưới UID 0 bên trong container. Vì các container chia sẻ kernel của host với các container khác và chính host, root bên trong một container không giống root trên một máy ảo được cô lập hoàn toàn — nhưng nó vẫn mạnh hơn nhiều so với những gì nó nên có. Nếu một kẻ tấn công đạt được thực thi mã bên trong một container sở hữu bởi root, họ thừa hưởng:

• Quyền truy cập đọc/ghi đầy đủ vào bất kỳ tập tin nào được gắn vào container, bất kể quyền dự định
• Khả năng cài đặt gói, sửa đổi tệp nhị phân hoặc can thiệp vào trạng thái ứng dụng
• Một con đường dễ dàng hơn nhiều để thoát khỏi container nếu có lỗ hổng kernel hoặc runtime có thể khai thác được
• Đòn bẩy nâng cao khi kết hợp với các tập tin được cấu hình sai, như một Docker socket được gắn hoặc đường dẫn hệ thống tập tin của host

Ngay cả không có khai thác kernel, quyền truy cập root bên trong container làm tăng đáng kể bán kính nổ của bất kỳ lỗ hổng cấp ứng dụng nào (SSRF, lỗi khước hóa, ghi tập tin tùy ý, v.v.).

Tại Sao Điều Này Quan Trọng Hơn Trong Các Môi Trường Được Sắp Xếp

Trong các cluster Kubernetes, một container root kết hợp với các khả năng Linux quá mức hoặc một ngữ cảnh bảo mật dễ tiếp cận có thể cho phép một kẻ tấn công:

• Sửa đổi /proc hoặc /sys theo những cách ảnh hưởng đến host
• Nâng cao đặc quyền nếu hostPID, hostNetwork hoặc hostIPC được bật
• Lạm dụng một token tài khoản dịch vụ được gắn để xoay trục ngang trên toàn cluster
• Thoát ra khỏi nút nếu privileged: true được đặt hoặc các khả năng nguy hiểm như SYS_ADMIN được cấp

Chính người dùng root không phải lúc nào cũng là lỗ hổng — đó là sự kết hợp của root cộng với các khả năng kernel quá hào phóng, gắn host hoặc chia sẻ không gian tên biến một thỏa hiệp được chứa đựng thành một thỏa hiệp toàn cluster.

Các Bước Cứng Hóa Thực Tiễn

1. Đặt Người Dùng Không Phải Root Trong Hình Ảnh

Các định rõ ràng một người dùng không phải root trong Dockerfile thay vì dựa vào các mặc định:

FROM node:20-slim
RUN useradd --uid 10001 --shell /usr/sbin/nologin appuser
USER appuser

2. Thực Thi Nó Ở Mức Orchestrator

Đừng chỉ tin tưởng hình ảnh — thực thi chính sách trong thời gian chạy. Trong Kubernetes, sử dụng securityContext:

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]

runAsNonRoot: true làm cho pod không được chấp nhận nếu hình ảnh cố gắng chạy dưới UID 0, cung cấp cho bạn một bảo đảm cứng thay vì một quy ước tốt nhất.

3. Thả Các Khả Năng Không Cần Thiết

Hầu hết các ứng dụng không cần bất kỳ khả năng Linux mặc định nào được cấp cho container. Thả tất cả và chỉ thêm lại những gì được yêu cầu nghiêm ngặt (các trường hợp hiếm như ràng buộc với các cổng thấp có thể cần NET_BIND_SERVICE).

4. Tránh Chế Độ Đặc Quyền Và Chia Sẻ Không Gian Tên Host

privileged: true, hostNetwork: true và hostPID: true nên được dành riêng cho các khối lượng công việc cơ sở hạ tầng rất cụ thể (như các đại lý CNI hoặc giám sát nhất định) — không bao giờ cho các container ứng dụng chung.

5. Quét Và Thực Thi Với Các Công Cụ Chính Sách

Sử dụng các bộ điều khiển thừa nhận hoặc các công cụ chính sách (ví dụ: Kyverno, OPA/Gatekeeeper) để từ chối tự động các triển khai vi phạm những quy tắc này, thay vì dựa vào đánh giá mã thủ công. Kết hợp điều này với quét hình ảnh trong CI để bắt các hình ảnh người dùng root trước khi chúng đến một cluster.

Một Phòng Thủ Nhiều Lớp, Không Hoàn Hảo

Chạy dưới quyền không phải root không loại bỏ rủi ro hoàn toàn — các vụ thoát khỏi container cấp kernel tồn tại độc lập với người dùng trong container — nhưng nó loại bỏ một lớp lớn các kỹ thuật nâng cao đặc quyền và chuyển động ngang nỗ lực thấp. Kết hợp với hệ thống tập tin chỉ đọc, các khả năng bị loại bỏ và các chính sách mạng hạn chế, nó tạo thành một trong những lớp rẻ nhất và hiệu quả nhất trong một chiến lược bảo mật container phòng thủ sâu.

Bạn muốn tìm hiểu sâu hơn về cứng hóa các khối lượng công việc gốc đám mây? Khám phá các phân đoạn Korra Studio liên quan đến bảo mật đám mây và cứng hóa đường ống DevOps để xây dựng phần còn lại của chiến lược phòng thủ sâu của bạn.