Docker Bench for Security: Quét sạch lỗ hổng Docker Host chuẩn CIS trong 5 phút

Docker tutorial - IT technology blog
Docker tutorial - IT technology blog

Vấn đề thực tế: Docker không tự an toàn như bạn nghĩ

Cách đây nửa năm, mình quản lý cụm 20 microservices chạy Docker cho một dự án tài chính. Mọi thứ vận hành rất trơn tru: CI/CD đẩy image liên tục, container tự scale, log đổ về Grafana đều đặn. Mình từng đinh ninh rằng Docker đã cô lập ứng dụng đủ tốt. Nếu hacker có xâm nhập, chúng cũng chỉ mắc kẹt trong cái “hộp” container đó thôi.

Mọi chuyện thay đổi khi đội Security gửi bản audit 15 trang với hơn 40 lỗi bảo mật nghiêm trọng. Docker daemon chạy quyền root, socket bị phơi bày, và container không hề có giới hạn tài nguyên. Tệ hơn, nhiều image dùng bản Node.js cũ từ 3 năm trước chứa đầy lỗ hổng Critical. Bài học rút ra rất đắt: Biết chạy Docker không đồng nghĩa với việc biết vận hành nó an toàn.

Nếu bạn chỉ quen tay docker run mà bỏ qua cấu hình Host hay Daemon, hệ thống của bạn rất dễ bị tấn công leo thang đặc quyền (privilege escalation). Đừng đợi đến khi server bị biến thành máy đào coin mới bắt đầu lo bảo mật.

Tại sao cấu hình mặc định của Docker lại nguy hiểm?

Docker ưu tiên sự tiện dụng để người dùng “chạy ngay lập tức”. Tuy nhiên, sự tiện lợi này thường đi kèm với các rủi ro tiềm ẩn:

  • Quyền hạn quá lớn: Docker daemon mặc định chạy dưới quyền root. Nếu bạn vô tình mount /var/run/docker.sock vào một container bị chiếm quyền, hacker sẽ kiểm soát toàn bộ máy host.
  • Tiêu chuẩn CIS quá đồ sộ: Bộ tiêu chuẩn CIS Docker Benchmark có hơn 100 hạng mục kiểm tra. Chẳng ai đủ kiên nhẫn ngồi đối chiếu thủ công hàng trăm trang PDF mỗi khi triển khai server mới.
  • Lỗ hổng từ Runtime: Chúng ta thường chỉ kiểm tra container có “Up” hay không. Rất ít người để ý xem nó có đang chạy với flag nguy hiểm như --privileged hay không.

Các giải pháp kiểm tra bảo mật phổ biến

Trước khi tìm thấy chân ái, mình đã thử qua vài phương pháp truyền thống:

  1. Hardening thủ công: Tự check file config, phân quyền lại /etc/docker, cấu hình auditd. Cách này cực kỳ tốn thời gian và dễ sai sót. Nó chỉ phù hợp nếu bạn đang ôn thi chứng chỉ bảo mật.
  2. Script Bash tự chế: Một số anh em viết script để check nhanh vài thông số. Tuy nhiên, script này thường nhanh lỗi thời khi Docker cập nhật phiên bản mới.
  3. Công cụ SaaS đắt tiền: Các giải pháp như Prisma Cloud hay Snyk rất mạnh mẽ. Nhưng với dự án startup hoặc cá nhân, chi phí hàng ngàn USD mỗi tháng là rào cản quá lớn.

Docker Bench for Security: Công cụ “ngon – bổ – rẻ”

Sau nhiều lần thử nghiệm, mình chốt lại Docker Bench for Security là giải pháp tối ưu nhất. Đây là một script mã nguồn mở được đóng gói vào container. Nó tự động quét hệ thống dựa trên toàn bộ các tiêu chuẩn của CIS Benchmarks.

Tại hệ thống production mình đang quản lý, tool này được đặt lịch chạy hàng tuần. Nó giúp mình phát hiện ngay những lỗi ngớ ngẩn như quên giới hạn RAM, vốn là nguyên nhân khiến một container bị lỗi có thể làm sập toàn bộ server.

1. Cách triển khai nhanh trong 10 giây

Điểm cộng lớn nhất là bạn không cần cài đặt thêm bất cứ thứ gì lên máy host. Chỉ cần thực thi lệnh sau để kéo image và bắt đầu quét:

docker run --rm -it --network host --pid host --userns host --cap-add audit_control \
    -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \
    -v /etc:/etc:ro \
    -v /usr/bin/containerd:/usr/bin/containerd:ro \
    -v /usr/bin/runc:/usr/bin/runc:ro \
    -v /usr/lib/systemd:/usr/lib/systemd:ro \
    -v /var/lib:/var/lib:ro \
    -v /var/run/docker.sock:/var/run/docker.sock:ro \
    --label docker_bench_security \
    docker/docker-bench-security

Giải thích các tham số quan trọng:

  • --pid host: Cho phép công cụ quan sát các tiến trình đang chạy trên host để kiểm tra tính toàn vẹn của Daemon.
  • -v /var/run/docker.sock:/var/run/docker.sock: Giúp tool giao tiếp trực tiếp với Docker API.
  • --rm: Tự động dọn dẹp container sau khi quét xong để giữ server sạch sẽ.

2. Phân tích kết quả quét

Kết quả trả về sẽ được phân loại theo màu sắc rất dễ nhìn:

  • [PASS]: Cấu hình đã an toàn theo chuẩn.
  • [WARN]: Cảnh báo nguy cơ bảo mật cần xem xét.
  • [INFO]: Thông tin tham khảo.
  • [NOTE]: Các vấn đề nghiêm trọng cần xử lý ngay.

Báo cáo thường tập trung vào 5 nhóm chính bao gồm cấu hình Host, thiết lập Daemon, quyền hạn file hệ thống, bảo mật Image và trạng thái Runtime của container.

3. Thực tế sửa lỗi: Chặn đứng tấn công nội bộ

Sau lần chạy đầu tiên, máy chủ của mình dính lỗi [WARN] 2.1 - Ensure network traffic is circumscribed.... Lỗi này có nghĩa là các container trong bridge network mặc định có thể tự do “nói chuyện” với nhau. Nếu một container bị nhiễm mã độc, nó sẽ dễ dàng tấn công các container còn lại.

Mình đã xử lý triệt để bằng cách cấu hình file /etc/docker/daemon.json như sau:

{
  "icc": false,
  "userns-remap": "default",
  "no-new-privileges": true
}

Sau đó chỉ cần khởi động lại dịch vụ:

sudo systemctl restart docker

Chỉ với 3 dòng cấu hình, mình đã chặn đứng khả năng Inter-Container Communication (ICC), tăng tính cô lập cho hệ thống.

4. Tự động hóa quy trình giám sát

Đừng để việc bảo mật là hứng thú nhất thời. Mình thiết lập một Cronjob để chạy Docker Bench hàng tuần và đẩy kết quả trực tiếp về Slack. Nếu ai đó vô tình bật flag --privileged khi deploy, mình sẽ nhận được cảnh báo ngay lập tức trong 5 phút.

# Script lưu log tự động hàng tuần
docker run --rm --network host --pid host docker/docker-bench-security > /var/log/docker-bench-$(date +%F).log

Kết quả sau 6 tháng áp dụng thực tế

Việc đưa Docker Bench vào quy trình vận hành mang lại những thay đổi rõ rệt:

  • Kỹ năng build image tốt hơn: Đội ngũ dev đã bỏ thói quen dùng quyền root, thay vào đó là sử dụng lệnh USER trong Dockerfile.
  • Tài nguyên ổn định: Việc ép buộc giới hạn CPU/RAM giúp server không bao giờ bị treo bất ngờ do rò rỉ bộ nhớ.
  • Uy tín với khách hàng: Khi audit định kỳ, mình chỉ cần xuất log từ Docker Bench là đủ để chứng minh hệ thống tuân thủ tiêu chuẩn quốc tế.

Đừng chủ quan với những thiết lập mặc định. Hãy dành ra 5 phút chạy thử Docker Bench for Security ngay hôm nay. Có thể kết quả sẽ khiến bạn hơi “toát mồ hôi”, nhưng thà sửa lỗi bây giờ còn hơn là xử lý sự cố sau này. Nếu bạn gặp khó khăn khi fix các lỗi [WARN], hãy để lại bình luận phía dưới nhé!

Share: