Khi làm việc với Docker, tôi có một nguyên tắc là trước khi triển khai bất kỳ ứng dụng nào lên production, tôi luôn đặt ra câu hỏi: Nếu tôi là một hacker, tôi sẽ tấn công hệ thống này như thế nào?. Tư duy này giúp tôi nhận ra nhiều vấn đề bảo mật quan trọng mà bình thường có thể bỏ qua. Docker rất tiện lợi, nhưng điều đó không có nghĩa là nó an toàn một cách mặc định. Trong bài viết hôm nay, tôi muốn chia sẻ với mọi người một vài kinh nghiệm về vấn đề này.

Vấn đề phổ biến và nguy hiểm nhất mà tôi thường thấy là việc chạy container với quyền root. Một kẻ tấn công khi phát hiện ra điều này sẽ có một lợi thế rất lớn, vì từ đó có thể có cơ hội leo thang đặc quyền ra cả máy chủ host. Vì vậy, tôi khuyên mọi người nên tạo một người dùng riêng trong Dockerfile và chuyển sang sử dụng người dùng đó.

Một yếu tố quan trọng khác là kích thước của image. Image có kích thước lớn thường chứa nhiều gói phần mềm không cần thiết, tạo ra bề mặt tấn công rộng hơn. Do đó, tôi luôn ưu tiên sử dụng các image tối giản nhất có thể, ví dụ như Alpine.

Để tối ưu hơn nữa, mọi người nên sử dụng kỹ thuật multi-stage build. Phương pháp này giúp loại bỏ tất cả các công cụ biên dịch và các file tạm ra khỏi image cuối cùng. Kẻ tấn công sẽ không có sẵn đồ nghề để thực hiện các hành vi xấu ngay trên container của bạn.

Tất nhiên, image gọn nhẹ không có nghĩa là nó an toàn. Tôi luôn có thói quen quét image thường xuyên bằng các công cụ như docker scan hay trivy để tìm các lỗ hổng đã được biết đến. Việc này nên được tích hợp vào quy trình CI/CD như một bước kiểm tra bắt buộc.

Tiếp theo là vấn đề về mạng. Một sai lầm nghiêm trọng là phơi các cổng dịch vụ nội bộ, như database, ra ngoài internet. Mọi người nên sử dụng mạng nội bộ của Docker để các container giao tiếp với nhau và chỉ mở những cổng thật sự cần thiết ra bên ngoài.

Tương tự như vậy là các thông tin nhạy cảm. Tôi thấy nhiều người vẫn lưu trữ key API hay mật khẩu trong các biến môi trường. Điều này không an toàn. Thay vào đó, mọi người nên sử dụng Docker secrets hoặc các hệ thống quản lý bí mật chuyên dụng.

Ngoài ra, mọi người nên chú ý dọn dẹp rác khi build image. Hãy sử dụng file .dockerignore để đảm bảo các file không cần thiết như .env hay node_modules không bị đưa vào image.

Đối với những ai muốn tăng cường bảo mật ở mức độ sâu hơn, hãy tìm hiểu về các hồ sơ bảo mật như AppArmor hay Seccomp. Chúng giúp giới hạn các lệnh gọi syscall mà một container có thể thực hiện, giảm thiểu đáng kể rủi ro. Một kỹ thuật khác mà tôi hay áp dụng là chạy container ở chế độ --read-only, điều này ngăn chặn kẻ tấn công ghi bất kỳ file nào lên hệ thống của container.

Cuối cùng, việc ghi log là vô cùng quan trọng. Nếu không có log, bạn sẽ không thể biết chuyện gì đã xảy ra khi có sự cố. Tôi khuyên mọi người nên chuyển tiếp log của container đến một hệ thống quản lý tập trung để dễ dàng theo dõi và phân tích khi cần.

Tóm lại, tất cả các biện pháp bảo mật này đều xoay quanh một tư duy cốt lõi: không tin tưởng mặc định. Mọi người nên luôn giả định rằng container của mình có thể bị tấn công. Việc áp dụng tư duy này sẽ giúp mọi người xây dựng được những hệ thống có khả năng chống chịu tốt hơn.