Kubernetes bài 5 - bảo mật Cloud Native và chuẩn DevSecOps cho K8s

Việc siết chặt an ninh (Hardening) không phải là cấu hình một vài thông số rồi bỏ đó, mà là một tư duy phòng thủ chiều sâu.

Kubernetes được thiết kế ban đầu với triết lý ưu tiên sự tiện dụng và tốc độ triển khai (Developer Experience). Hệ quả là các thiết lập mặc định của nó thường rất lỏng lẻo về mặt an ninh. Nếu bạn mang nguyên một cụm Kubernetes cài đặt mặc định phơi ra ngoài Internet, chỉ mất chưa đầy vài giờ để hệ thống của bạn biến thành một mỏ đào tiền ảo khổng lồ cho hacker.

Việc siết chặt an ninh (Hardening) không phải là cấu hình một vài thông số rồi bỏ đó, mà là một tư duy phòng thủ chiều sâu. Dưới góc nhìn thực chiến, chúng ta sẽ áp dụng các nguyên tắc bảo mật chặt chẽ nhất từ hạ tầng vật lý lên đến từng dòng code.

Bức tranh toàn cảnh về bảo mật đa tầng Cloud Cluster Container và Code

Trong kỷ nguyên hệ thống phân tán, các ranh giới mạng truyền thống không còn tồn tại. Để không bỏ sót bất kỳ lỗ hổng nào, giới bảo mật đám mây áp dụng mô hình phòng thủ bốn lớp đồng tâm, thường được gọi là mô hình bốn chữ C.

Lớp ngoài cùng là Cloud đại diện cho cơ sở hạ tầng nền tảng. Ở lớp này, chúng ta phải bảo vệ mạng vật lý, tường lửa của trung tâm dữ liệu và hệ thống quản lý định danh (IAM) của nhà cung cấp dịch vụ đám mây. Nếu hacker chiếm được tài khoản quản trị AWS hay Google Cloud của bạn, mọi lớp bảo mật bên trong đều vô nghĩa.

Lớp thứ hai là Cluster bao gồm các thành phần cốt lõi của Kubernetes mà chúng ta đã nhắc đến ở bài đầu tiên. Trọng tâm ở đây là bảo vệ API Server, mã hóa dữ liệu tĩnh trong etcd và thiết lập tường lửa nội bộ giữa các ứng dụng.

Lớp thứ ba là Container nơi các kỹ sư phải đảm bảo rằng các image chứa ứng dụng không tồn tại lỗ hổng bảo mật đã biết (CVE), không chứa mã độc và được xây dựng từ những hệ điều hành nền tối giản nhất (Distroless image) để thu hẹp bề mặt tấn công.

Lớp trong cùng là Code liên quan trực tiếp đến mã nguồn của ứng dụng. Quá trình kiểm thử an toàn tĩnh và động (SAST/DAST) phải được tích hợp thẳng vào luồng CI/CD để phát hiện sớm các lỗi SQL Injection hay XSS trước khi chúng kịp đóng gói thành container.

Thiết lập cơ chế phân quyền chuẩn doanh nghiệp để tránh bẫy lạm quyền

Khi hệ thống bắt đầu có nhiều nhóm phát triển (Dev) và nhóm vận hành (Ops) cùng làm việc, rủi ro nội bộ trở thành mối đe dọa lớn nhất. Rất nhiều sự cố thảm khốc xảy ra chỉ vì một kỹ sư thực tập vô tình gõ lệnh xóa nhầm toàn bộ namespace trên môi trường Production do được cấp quyền quá rộng.

Kubernetes kiểm soát quyền hạn thông qua cơ chế Role-Based Access Control (RBAC). Hệ thống này xoay quanh nguyên tắc quyền đặc quyền tối thiểu (Principle of Least Privilege). Tuy nhiên, bẫy lạm quyền thường xảy ra khi quản trị viên vì lười biếng nên đã gán thẳng quyền cluster-admin (quyền tối thượng có thể làm mọi thứ) cho các thành viên trong đội dự án.

Để thiết lập chuẩn doanh nghiệp, chúng ta phải chia nhỏ quyền hạn ra. Nếu một nhóm phát triển chỉ phụ trách dự án thanh toán, họ sẽ được cấp một Role chỉ có quyền xem log và khởi động lại Pod trong duy nhất Namespace thanh toán đó. Họ tuyệt đối không có quyền đọc Secret chứa mật khẩu database, cũng không thể can thiệp vào Namespace của dự án nhân sự. Bằng cách sử dụng RoleBinding, chúng ta trói chặt quyền hạn của một người dùng hoặc một tài khoản dịch vụ (Service Account) vào một ranh giới an toàn, ngăn chặn hoàn toàn nguy cơ phá hoại chéo.

Ngăn chặn thảm họa chiếm quyền điều khiển nút vật lý từ bên trong container

Một lầm tưởng chết người của nhiều lập trình viên là tin rằng container giống như một máy ảo (VM) cách ly hoàn toàn. Thực tế, xét ở tầng Kernel, container chỉ là một tiến trình thông thường của Linux được khoác thêm một tấm áo ảo hóa bằng công nghệ Namespaces và cgroups.

Nếu bạn để cho tiến trình bên trong container chạy dưới quyền root, hoặc tệ hơn là bật chế độ privileged trong file cấu hình YAML, bạn đang trao cho ứng dụng đó chìa khóa vạn năng để thao tác trực tiếp với phần cứng của Worker Node.

Khi một ứng dụng web dính lỗ hổng thực thi mã từ xa (RCE), hacker sẽ lấy được Shell bên trong container. Nếu phát hiện container đang chạy quyền root, chúng có thể sử dụng kỹ thuật Container Escape để thoát ra khỏi lớp vỏ bọc này, leo thang đặc quyền để tương tác trực tiếp với nhân Linux của máy chủ vật lý vật lý (Host Kernel). Từ đây, hacker có thể xóa toàn bộ dữ liệu máy chủ, lây nhiễm mã độc sang các container khác hoặc phá hủy toàn bộ Node.

Biện pháp phòng thủ ở đây là áp dụng Pod Security Standards để loại bỏ các năng lực không cần thiết của Linux (Drop Capabilities). Ứng dụng bắt buộc phải chạy bằng một người dùng không có đặc quyền (non-root user), hệ thống tệp root (Root Filesystem) phải được mount ở chế độ chỉ đọc (Read-Only) để hacker dù có vào được cũng không thể tải thêm các công cụ phá hoại về máy.

Tự động hóa kiểm soát chính sách an ninh bằng công cụ Admission Controllers

Dù chúng ta có ban hành bao nhiêu quy định bảo mật cho đội ngũ lập trình, lỗi con người vẫn sẽ luôn xảy ra. Một ai đó vẫn có thể vô tình đẩy một file cấu hình yêu cầu quyền root lên hệ thống. Để giải quyết dứt điểm vấn đề này theo chuẩn DevSecOps, chúng ta cần một người gác cổng thép tự động hóa.

Trong quy trình xử lý API của Kubernetes, sau khi xác thực danh tính và kiểm tra quyền hạn, yêu cầu sẽ phải đi qua một chốt chặn cuối cùng mang tên Admission Controllers.

Sử dụng các công cụ mạnh mẽ như OPA Gatekeeper hay Kyverno, chúng ta có thể lập trình ra các chính sách an ninh bắt buộc. Ví dụ, thiết lập một chính sách từ chối mọi yêu cầu tạo Pod nếu image đó tải về từ một kho lưu trữ công cộng không đáng tin cậy như Docker Hub, thay vì kho nội bộ của công ty. Hoặc một chính sách khác sẽ ngay lập tức chặn đứng (Block) bất kỳ file YAML nào có khai báo chạy ở chế độ đặc quyền hoặc thiếu cấu hình giới hạn CPU/RAM.

Nhờ những người gác cổng tự động này, mọi lỗ hổng từ phía con người đều được phát hiện và ngăn chặn ngay từ vòng gửi xe, đảm bảo môi trường Production luôn trong trạng thái vô trùng và tuân thủ nghiêm ngặt các tiêu chuẩn an toàn thông tin toàn cầu.