Kubernetes bài 3 - Bảo mật cấu hình k8s và config Security trên Production

Kubernetes giải quyết bài toán này bằng hai đối tượng chuyên biệt nhưng nếu không hiểu rõ bản chất bảo mật ở tầng dưới, bạn đang tự tay dâng toàn bộ chìa khóa hệ thống cho hacker.

Sau khi đã thiết lập được luồng giao tiếp mạng an toàn giữa các Pod ở Bài 2, bài toán tiếp theo hệ thống phải đối mặt là làm sao cung cấp cấu hình và mật khẩu cho các ứng dụng này hoạt động. Một nguyên tắc sống còn trong phát triển phần mềm hiện đại là tách biệt hoàn toàn mã nguồn khỏi cấu hình. Nếu bạn vô tình hardcode mật khẩu database vào trong image Docker, kẻ tấn công chỉ cần kéo image đó về là có thể chiếm toàn quyền hệ thống.

Tách biệt cấu hình khỏi mã nguồn với ConfigMap và Secret

Theo triết lý 12-Factor App, một ứng dụng chuẩn Cloud Native phải được build thành một image duy nhất và có thể chạy ở mọi môi trường (Dev, Staging, Production) mà không cần build lại. Sự khác biệt giữa các môi trường chỉ nằm ở các biến số môi trường và file cấu hình.

Kubernetes cung cấp ConfigMap để lưu trữ các dữ liệu không nhạy cảm. Bạn có thể dùng nó để chứa đường dẫn URL của các dịch vụ nội bộ, cấu hình Nginx, hoặc các biến môi trường thông thường. ConfigMap giúp bạn thay đổi cấu hình mà không cần phải đụng chạm đến mã nguồn gốc của ứng dụng.

Khi đối mặt với dữ liệu nhạy cảm như mật khẩu cơ sở dữ liệu, API key hay chứng chỉ TLS, Kubernetes cung cấp đối tượng Secret. Về mặt sử dụng, Secret khá giống ConfigMap, chúng có thể được tiêm (inject) vào Pod dưới dạng các biến môi trường (Environment Variables) hoặc được gắn (mount) thành các file vật lý bên trong hệ thống file của container.

Tuy nhiên sự khác biệt lớn nhất nằm ở cách Kubernetes xử lý và lưu trữ hai loại dữ liệu này ở hậu trường.

Lỗ hổng chết người từ cơ chế mã hóa Base64 mặc định

Rất nhiều kỹ sư khi mới chuyển từ hệ thống truyền thống lên Kubernetes mang một lầm tưởng vô cùng nguy hiểm rằng Secret là một nơi lưu trữ mật khẩu an toàn vì dữ liệu bên trong trông có vẻ đã được mã hóa.

Sự thật phũ phàng là mặc định Kubernetes không hề mã hóa Secret. Ký tự lộn xộn mà bạn nhìn thấy trong file manifest chỉ là định dạng Base64 – một dạng mã hóa chuỗi (encoding) chứ không phải là mã hóa bảo mật (encryption). Bất kỳ ai có quyền đọc file Secret đó đều có thể dùng một lệnh giải mã đơn giản trên terminal để lấy được mật khẩu gốc dạng văn bản thuần túy (plaintext).

Nghiêm trọng hơn, toàn bộ dữ liệu của Cluster được lưu trữ trong cơ sở dữ liệu etcd. Nếu bạn không thiết lập mã hóa dữ liệu tĩnh (Encryption at Rest) cho etcd, một kẻ tấn công leo thang đặc quyền thành công vào Master Node, hoặc có quyền truy cập vào file backup của etcd, hắn có thể gom trọn ổ toàn bộ thông tin nhạy cảm nhất của doanh nghiệp mà không cần tốn công giải mã.

Các giải pháp bảo mật Secret chuẩn doanh nghiệp thực chiến

Để vận hành an toàn trên môi trường Production, chúng ta bắt buộc phải can thiệp vào cách Kubernetes xử lý Secret. Tùy thuộc vào quy mô và ngân sách, có ba cách tiếp cận chuyên nghiệp để giải quyết lỗ hổng mã hóa.

Cách thứ nhất là kích hoạt Encryption at Rest ngay từ lớp API Server. Bằng cách tích hợp với một nhà cung cấp quản lý khóa (KMS - Key Management Service) như AWS KMS hay Google Cloud KMS, dữ liệu Secret trước khi ghi xuống etcd sẽ được mã hóa bằng thuật toán chuẩn xác. Kẻ gian dù có ăn cắp được file database etcd cũng chỉ thu về những khối dữ liệu vô nghĩa.

Cách thứ hai là sử dụng mô hình External Secrets. Trong các hệ thống Microservices quy mô lớn, việc để các team tự quản lý Secret trong file YAML là rất rủi ro. Thay vào đó, toàn bộ mật khẩu sẽ được lưu trữ tập trung ở các "két sắt" chuyên dụng như HashiCorp Vault. Ứng dụng khi khởi động sẽ tự động xác thực và kéo mật khẩu từ Vault về bộ nhớ tạm thời, không để lại bất kỳ dấu vết nào trên Kubernetes.

Cách thứ ba cực kỳ phổ biến trong xu hướng GitOps hiện nay là sử dụng Sealed Secrets hoặc SOPS. Kỹ thuật này sử dụng mã hóa bất đối xứng. Nhà phát triển sẽ dùng Public Key để mã hóa thật sự file Secret ngay trên máy tính cá nhân trước khi đẩy lên Github. Khi file này được đưa vào Kubernetes, một Controller đặc biệt đang giữ Private Key sẽ đứng ra giải mã và cung cấp cho ứng dụng.

Cơ chế mount dữ liệu tầng Kernel và Quản lý ổ đĩa lưu trữ

Câu hỏi cuối cùng là khi Secret được giải mã và đưa vào Pod, nó sẽ tồn tại ở đâu.

Từ góc độ Kernel, khi bạn cấu hình mount Secret thành các file bên trong container, Kubernetes không ghi các file này xuống ổ cứng vật lý của Worker Node. Thay vào đó, nó sử dụng tmpfs – một hệ thống tập tin nằm hoàn toàn trên bộ nhớ RAM. Điều này đảm bảo hiệu năng đọc cực nhanh và quan trọng nhất là tính phù du. Ngay khi Pod bị xóa hoặc Node bị tắt, toàn bộ dữ liệu nhạy cảm trên RAM sẽ bốc hơi ngay lập tức, không để lại dấu vết để các kỹ thuật khôi phục dữ liệu (Data Recovery Forensics) có thể khai thác.

Đối với các dữ liệu cần lưu trữ lâu dài (Stateful data) như database, Kubernetes không dùng tmpfs mà sử dụng hệ thống Persistent Volume (PV) và Persistent Volume Claim (PVC). Thông qua chuẩn giao tiếp lưu trữ Container Storage Interface (CSI), Kubernetes có thể gọi trực tiếp API của các nền tảng Cloud để tạo ra một ổ cứng vật lý (như AWS EBS) và gắn chặt nó vào Node đang chạy Pod. Khi Pod chết và chuyển sang Node khác chạy, Kubernetes sẽ tự động tháo ổ cứng ở Node cũ và lắp sang Node mới, đảm bảo dữ liệu kinh doanh luôn được toàn vẹn và xuyên suốt.