Thứ Bảy, 28/02/2026, 17:00 (GMT+0)

Kubernetes Policy Management: Nền tảng đảm bảo an ninh, tuân thủ và quản trị trong Kubernetes Service

Quay lại Trang chủ Blog
Trên trang này

Kubernetes Service giúp tăng tốc triển khai ứng dụng nhưng cũng kéo theo nhiều thách thức về bảo mật và quản trị. Để giải quyết bài toán này, Kubernetes Policy Management được sử dụng nhằm kiểm soát cấu hình, chuẩn hóa vận hành và giảm rủi ro trong môi trường cluster. Bài viết sẽ điểm qua các cơ chế policy phổ biến trong Kubernetes và minh họa bằng một case thực tế về yêu cầu read-only root filesystem.

Thách thức quản trị và bảo mật trong Kubernetes Service

Môi trường Kubernetes Service, với khả năng quản lý và triển khai ứng dụng một cách linh hoạt, đã trở thành nền tảng ưa chuộng cho việc phát triển và triển khai các ứng dụng dựa trên containers. Tuy nhiên, với sức mạnh đến từ tính linh hoạt cũng đi kèm với những thách thức đáng kể:

  • Thách thức về an ninh: Môi trường containerized thường phải đối mặt với những mối đe dọa an ninh ngày càng tinh vi và đa dạng. Việc triển khai ứng dụng trong các container mở ra cánh cửa cho những lỗ hổng an ninh mới, đặt ra nhu cầu cần phải giải quyết một cách toàn diện để bảo vệ hệ thống khỏi các mối đe dọa này.
  • Thách thức quản lý tài nguyên: Việc quản lý hiệu suất và tài nguyên trong môi trường Kubernetes là một thách thức lớn. Sự đa dạng của các ứng dụng và yêu cầu của chúng có thể dẫn đến tình trạng quá tải hoặc không tận dụng đủ tài nguyên, ảnh hưởng đến hiệu suất và khả năng mở rộng của hệ thống.
  • Thách thức tính nhất quán và quy trình triển khai: Với sự đa dạng của các công nghệ và quy trình triển khai, làm thế nào để đảm bảo tính nhất quán giữa các ứng dụng và triển khai chúng trở thành một câu hỏi quan trọng. Sự không nhất quán có thể dẫn đến lỗi không dễ phát hiện và khó khăn trong việc duy trì hệ thống.
  • Thách thức quản lý chuẩn mực doanh nghiệp: Mỗi doanh nghiệp có những yêu cầu và chuẩn mực riêng biệt. Việc quản lý và tuân thủ các quy tắc, chuẩn mực an ninh, và quy trình doanh nghiệp là một thách thức đối với mọi tổ chức.
kubernetes-policy-management

Đối mặt với những thách thức trên, việc sử dụng các policy trong Kubernetes Service trở nên quan trọng hơn bao giờ hết. Những policy này trở thành một yếu tố quan trọng để duy trì sự ổn định, an ninh và hiệu suất trong môi trường containerized.

Tổng quan và vai trò của Kubernetes Policy Management 

Quản lý chính sách là một dạng quản lý cấu hình, trong đó chính sách cung cấp các giá trị mặc định cho cấu hình và cũng xác định những gì được phép hoặc không được phép.

Bằng cách áp dụng các công cụ và phương pháp quản lý chính sách, các tổ chức có thể:

Đảm bảo an toàn cho các container và pod

  • Network Policies (Kiểm soát lưu lượng mạng giữa các pod),
  • Pod Security Policies (Định nghĩa các yêu cầu bảo mật cho pod, như quyền hạn, cấu hình network, và sử dụng volume),
  • Admission Controllers (Được sử dụng để thực thi các chính sách khi một pod hoặc một tài nguyên khác được tạo hoặc cập nhật).

Tối ưu hóa và kiểm soát việc sử dụng tài nguyên

  • Resource Quotas (Định nghĩa các giới hạn tài nguyên (CPU, memory, storage) cho các namespace để tránh việc sử dụng quá nhiều tài nguyên) và
  • Limit Ranges (Đặt các giới hạn cho từng container trong một namespace về việc sử dụng tài nguyên).

Quản lý quyền truy cập

  • RBAC (Quản lý quyền truy cập của người dùng và nhóm người dùng vào các tài nguyên trong cluster) và
  • Service Accounts (Tạo và quản lý các tài khoản dịch vụ cho phép các pod truy cập vào các tài nguyên Kubernetes).

Đảm bảo tuân thủ các quy định và tiêu chuẩn

  • OPA (Một công cụ mã nguồn mở cho phép tạo và thực thi các chính sách phức tạp trong Kubernetes) và
  • Kyverno (Một công cụ quản lý chính sách Kubernetes dễ sử dụng, cho phép tự động hoá và đảm bảo tuân thủ chính sách).

Các cơ chế Policy phổ biến trong Kubernetes

RBAC (Role-Based Access Control)

kubernetes-policy-management-2

RBAC (Role-Based Access Control) là cơ chế phân quyền truy cập API Kubernetes, dùng để xác định:

  • Ai (User / Group / ServiceAccount)
  • Được phép thực hiện hành động gì (get, list, create, update, delete…)
  • Trên tài nguyên nào (Pod, Deployment, Service, ConfigMap…)

RBAC hoạt động thông qua các đối tượng:

  • Role / ClusterRole: định nghĩa tập quyền
    RoleBinding / ClusterRoleBinding: gán quyền cho đối tượng cụ thể

RBAC là thành phần bắt buộc trong Kubernetes và là nền tảng cho mọi mô hình bảo mật, tuy nhiên RBAC không kiểm soát nội dung cấu hình của workload (ví dụ: container có chạy privileged hay không).

PodSecurityPolicy (PSP)

kubernetes-policy-management-3

PodSecurityPolicy (PSP) từng được sử dụng để kiểm soát các thuộc tính bảo mật của Pod, như:

  • Chạy container ở chế độ privileged
  • Sử dụng hostPath
  • Chạy với quyền root
  • Cấu hình capabilities và seccomp

Tuy nhiên, PSP đã bị loại bỏ hoàn toàn từ Kubernetes v1.25 do thiết kế phức tạp, khó sử dụng và khó vận hành trong môi trường production.

Pod Security Admission (PSA)

Gemini_Generated_Image_yifmcmyifmcmyifm.png

Pod Security Admission (PSA) là cơ chế thay thế PSP, được tích hợp sẵn trong Kubernetes dưới dạng admission controller.

PSA áp dụng các chuẩn bảo mật cho Pod theo 3 mức:

  • privileged: cho phép mọi cấu hình
  • baseline: chặn các hành vi nguy hiểm phổ biến
  • restricted: áp dụng best-practice bảo mật nghiêm ngặt

PSA được cấu hình thông qua label trên namespace, giúp triển khai đơn giản và đồng nhất. Tuy nhiên, PSA không hỗ trợ rule tùy chỉnh và chỉ giới hạn ở phạm vi Pod-level.

Open Policy Agent (OPA)

kubernetes-policy-management-6

Open Policy Agent (OPA) là một engine Policy-as-Code tổng quát, cho phép định nghĩa và thực thi các chính sách bảo mật và tuân thủ.

Trong Kubernetes, OPA thường được triển khai thông qua Gatekeeper, cho phép:

  • Kiểm soát request trước khi ghi vào API Server
  • Viết rule bằng ngôn ngữ Rego
  • Áp dụng policy cho nhiều loại tài nguyên khác nhau

OPA phù hợp với các hệ thống lớn, đa nền tảng và yêu cầu chính sách phức tạp, tuy nhiên đòi hỏi kiến thức chuyên sâu về Rego và việc debug tương đối khó.

Kyverno

Gemini_Generated_Image_4ps3pl4ps3pl4ps3 – Đã sửa.png

Kyverno là một policy engine dành riêng cho Kubernetes, cho phép viết policy hoàn toàn bằng YAML, không cần học ngôn ngữ mới.

Kyverno hỗ trợ nhiều loại chính sách:

  • Validate: từ chối resource không hợp lệ
  • Mutate: tự động chỉnh sửa manifest
  • Generate: tự động tạo resource liên quan
  • Verify Images: xác thực chữ ký image container

Kyverno đặc biệt phù hợp với mô hình GitOps và các team DevOps nhờ cú pháp quen thuộc và khả năng tích hợp sâu với Kubernetes.

Mục đích của Kubernetes policy management

Việc sử dụng các policy trong Kubernetes Service không chỉ giúp giải quyết các thách thức nói trên mà còn tạo ra một cơ sở hạ tầng linh hoạt và an toàn cho sự phát triển và triển khai ứng dụng:

  • An ninh và tuân thủ chuẩn mực: trong môi trường cloud, an ninh luôn là mối quan tâm hàng đầu, các policy giúp đảm bảo rằng các tài nguyên và ứng dụng tuân thủ các tiêu chuẩn an ninh và tuân thủ các chuẩn mực quy định.
  • Quản lý truy cập và phân quyền: các policy hỗ trợ quản lý quyền truy cập và phân quyền trong Kubernetes, đảm bảo rằng các nguồn tài nguyên chỉ được truy cập bởi các đối tượng được ủy quyền.
  • Quản lý hiệu suất và tài nguyên: policies có thể giúp kiểm soát và quản lý việc sử dụng tài nguyên, đảm bảo rằng các ứng dụng không ảnh hưởng tiêu cực đến hiệu suất của nhau hoặc của toàn bộ cluster.
  • Quản lý vấn đề ứng dụng: đối với các ứng dụng chạy trên Kubernetes Service, quản lý vấn đề như lỗi triển khai, các điều kiện cần thiết cho Pod, và các vấn đề khác có thể được đối phó một cách tự động thông qua việc thiết lập các policy.
  • Duy trì chuẩn mực quy trình triển khai: các policy giúp duy trì chuẩn mực quy trình triển khai, giảm thiểu sự phức tạp và tăng tính nhất quán trong quy trình triển khai của các ứng dụng.
  • Quản lý tài nguyên nguồn: với việc nguồn cung cấp ngày càng đa dạng, việc sử dụng policy giúp quản lý nguồn cung cấp tài nguyên, kiểm soát quy mô và chi phí.
  • Tự động hóa quy trình kiểm thử và kiểm tra: các policy có thể giúp tự động hóa quy trình kiểm thử và kiểm tra, đảm bảo rằng ứng dụng đáp ứng các tiêu chí chất lượng và an ninh.
  • Quản lý thời gian uptime: các policy có thể được sử dụng để theo dõi và quản lý thời gian uptime của ứng dụng, giúp dự đoán và ngăn chặn sự cố.
  • Quản lý cập nhật và tương thích: policy giúp kiểm soát quá trình cập nhật và đảm bảo tính tương thích của các phiên bản khác nhau của ứng dụng và tài nguyên.

Ứng dụng Policy vào bài toán thực tế: Require Read-Only Root Filesystem 

Vấn đề

Việc cho phép ghi data vào root filesystem chứa nhiều rủi ro:

  • Rủi ro an ninh: vì có thể có khả năng ghi dữ liệu vào root filesystem, tạo cơ hội cho tấn công từ các file binaries độc hại.
  • Không duy trì tính bất biến: thiếu sự đảm bảo về tính bất biến của hạ tầng vì không có yêu cầu về việc chỉ có quyền đọc trên root filesystem, làm suy giảm khả năng duy trì trạng thái của container thông qua ghi trên volume lưu trữ trạng thái.
  • Tăng khả năng tấn công: tăng cơ hội cho tấn công từ phía container do khả năng thay đổi root filesystem không bị hạn chế. Không có giới hạn nào ngăn chặn việc ghi dữ liệu độc hại từ container vào hệ thống host, làm tăng khả năng bị ảnh hưởng bởi malware hoặc tấn công khác.
  • Thay đổi không kiểm soát: thiếu sự kiểm soát đối với việc container có thể thay đổi root filesystem, tạo điều kiện cho khả năng thay đổi không kiểm soát và không mong muốn.
  • Bảo mật hệ thống host yếu hơn: thiếu biện pháp bảo mật mạnh mẽ để ngăn chặn việc ghi dữ liệu từ container vào hệ thống host, có thể tạo điều kiện cho các tấn công có thể ảnh hưởng đến hệ thống host.

Giải quyết vấn đề

Policy: Require Read-Only Root Filesystem

Policy này đảm bảo rằng root filesystem chỉ có quyền đọc bằng cách yêu cầu cấu hình bảo mật bắt buộc trong container.

Yêu cầu cấu hình:

securityContext:
readOnlyRootFilesystem: true

Cơ chế kiểm soát:

Nếu Pod không tuân thủ yêu cầu trên:

  • Admission Controller sẽ từ chối triển khai
  • Hệ thống trả về thông báo lỗi: "readOnlyRootFilesystem" in securityContext must be "true"

Điều này đảm bảo policy được thực thi ngay tại thời điểm deploy, thay vì chờ đến khi container đã chạy.

Mục đích

Policy này tập trung vào việc bảo vệ tính an ninh, hỗ trợ tính bất biến và mang lại nhiều lợi ích về an toàn, tính ổn định và bảo mật trong môi trường IDG Kubernetes Service:

  • Giảm rủi ro an ninh: bằng cách không cho phép ghi vào root filesystem, ngăn chặn các tấn công từ phía container và giảm khả năng bị ảnh hưởng từ file binaries độc hại.
  • Tính bất biến: hỗ trợ tính bất biến của hạ tầng bằng cách đảm bảo rằng root filesystem không thay đổi, giúp duy trì tính ổn định và nhất quán.
  • Bảo mật hệ thống host: ngăn chặn việc ghi dữ liệu từ container vào hệ thống host, bảo vệ hệ thống host khỏi tác động tiêu cực từ phía container.
  • Duy trì trạng thái container: hỗ trợ duy trì trạng thái của container thông qua ghi trên volume lưu trữ trạng thái, giúp duy trì tính ổn định và khả năng khôi phục.

Ví dụ cấu hình

Tuân thủ

Không tuân thủ

apiVersion: v1

kind: Pod

metadata:

 name: test-rorf-pass

spec:

 containers:

 - name: busybox

   image:busybox:1.34.0

   command: ["sh", "-c", 'while true; do echo "Hello"; sleep 2h; done']

   securityContext:

     readOnlyRootFilesystem: true
apiVersion: v1

kind: Pod

metadata:

 name: test-rorf-fail

spec:

 containers:

 - name: busybox

   image: busybox:1.34.0

   command: ["sh", "-c", 'while true; do echo "Hello"; sleep 2h; done']

Trong môi trường Kubernetes ngày càng phức tạp, policy management không còn là lớp kiểm soát bổ sung mà đã trở thành nền tảng quan trọng để đảm bảo bảo mật, tính nhất quán và khả năng vận hành ổn định của hệ thống. Việc áp dụng đúng các cơ chế policy giúp doanh nghiệp chủ động ngăn ngừa rủi ro, chuẩn hóa quy trình triển khai và nâng cao hiệu quả quản trị cluster trong dài hạn.

Nếu doanh nghiệp đang tìm kiếm một nền tảng Kubernetes Service đáp ứng tốt yêu cầu về quản trị, bảo mật và khả năng mở rộng, VNPT Cloud là lựa chọn đáng cân nhắc với hạ tầng mạnh mẽ, dịch vụ ổn định và đội ngũ kỹ thuật sẵn sàng đồng hành trong quá trình triển khai, vận hành và tối ưu hệ thống container trên cloud.

#CloudWave Radar
#CloudWave Radar
Chúng tôi có 4 môi trường staging, 2 môi trường production, hàng chục microservice và rất nhiều phiên bản thử nghiệm. Lúc đầu dùng VPS tưởng là đủ, nhưng rồi mỗi lần cập nhật code là một lần lo… không biết lần này ‘tháo’ có làm hỏng cái gì không?
Tại sao doanh nghiệp hiện đại cần Kubernetes?
Tiếp tục đọc