Least privilege cho container
Giảm blast radius khi ứng dụng bị khai thác.
Nắm bản chất
Chạy bằng UID không phải root và giảm Linux capabilities làm hẹp quyền của tiến
trình. --cap-drop=ALL, --read-only,
--security-opt no-new-privileges và resource limits hữu ích khi ứng
dụng không cần các quyền bị hạn chế.
Hardening phải kiểm tra application dependencies: một service cần ghi logs ra
stdout, ghi tạm vào /tmp có thể cần tmpfs mount. Trên Kubernetes,
sử dụng securityContext,
seccompProfile: RuntimeDefault và read-only root filesystem tương
ứng.
Luồng hoạt động
Hãy tự giải thích mỗi mũi tên: dữ liệu, quyền hoặc tín hiệu nào được truyền qua bước này?
Lệnh & cấu hình mẫu
docker run --rm --read-only --cap-drop=ALL --security-opt no-new-privileges:true --user 10001:10001 --tmpfs /tmp:rw,noexec,nosuid,size=16m alpine:3.20 id
Lệnh có placeholder hoặc phụ thuộc môi trường thì cần thay thông tin thực tế, kiểm tra quyền và chỉ thực hiện trên tài nguyên được phép.
Bài tập 10–20 phút
Chạy lab Buổi 7, kiểm tra UID và capabilities trước/sau hardening; thử một ứng dụng cần ghi file xem mount nào thực sự cần writable.
Lỗi dễ mắc
Không sử dụng --privileged chỉ để xử lý lỗi permission không
hiểu. Nó mở rộng quyền container đáng kể trên host.
Tự kiểm tra
Chạy UID không phải root đã loại bỏ mọi nguy cơ container escape chưa?Xem đáp án ↗
Chưa. Kernel, runtime, capabilities, mount, syscall và nhiều lớp khác vẫn cần bảo vệ.
Học thêm qua lab
Có project thực hành đúng với chương này, kèm README và những giới hạn môi trường cần lưu ý.
↓ Tải mã nguồn thực hành chương 07Đối chiếu tài liệu gốc
Cú pháp và khả năng hỗ trợ có thể thay đổi theo phiên bản. Trước khi dùng Production, hãy kiểm tra tài liệu tương ứng.
Mở tài liệu chính thức ↗