Bảo mật container dựa trên Kubernetes Pod Security Standards và Pod Security Admission

1. Tổng quan

Định nghĩa: Kubernetes Pod Security Standards (PSS) định nghĩa quyền hạn và chức năng cô lập mà Pod được phép sử dụng thành ba hồ sơ bảo mật có tính tích lũy, còn Pod Security Admission (PSA) là cơ chế kiểm soát tiếp nhận (admission control) tích hợp sẵn áp dụng các hồ sơ đó ở cấp namespace theo các chế độ enforce, audit, warn.

Container cô lập tiến trình và hệ thống tệp, nhưng nếu thiết lập cô lập yếu, nó có thể chia sẻ namespace mạng, tiến trình, IPC của máy chủ hoặc được cấp Linux capability quá mức. Các thiết lập như privileged: true tăng sự tiện lợi cho container nhưng đồng thời mở rộng đáng kể bề mặt tấn công cho việc thoát khỏi container hay chiếm quyền máy chủ. Vì vậy, chỉ kiểm tra lỗ hổng image là chưa đủ, mà phải xác minh nhất quán quyền thực thi của Pod tại thời điểm triển khai.

PodSecurityPolicy (PSP) ban đầu từng được sử dụng, nhưng bắt đầu lộ trình loại bỏ từ Kubernetes 1.21 và bị gỡ bỏ ở 1.25. PSA áp dụng PSS bằng admission controller tích hợp của API server mà không cần cài đặt webhook riêng. Tuy nhiên, PSA không phải là công cụ chính sách đa năng có thể biểu diễn mọi chính sách bảo mật container, nên phải thiết kế theo lớp cùng với chính sách mạng, chữ ký image và phát hiện runtime.

PSS tách biệt nội dung chính sách và cách áp dụng. Bản thân chính sách nói lên "yêu cầu mức bảo mật Pod nào", còn chế độ của PSA quyết định sẽ từ chối, ghi nhận hay cảnh báo người dùng khi vi phạm. Có sự tách biệt này mới có thể tái sử dụng cùng một tiêu chuẩn cho các cụm phát triển, kiểm thử và vận hành mà vẫn tăng cường enforcement dần dần.

Trang mới nhất của tài liệu chính thức Kubernetes giải thích ba hồ sơ, các chế độ, nhãn namespace, cố định phiên bản và thiết lập miễn trừ. Phiên bản tài liệu có thể khác với phiên bản cụm, nên trong thiết kế vận hành phải kiểm tra tài liệu PSS phù hợp với phiên bản control plane và kubelet thực tế.

1.1 Bối cảnh ra đời và sự cần thiết

Thứ nhất, container image chỉ là thành phần cấu tạo nên ứng dụng chứ không phải yếu tố quyết định cuối cùng về quyền thực thi. Dù dùng cùng một image, mức rủi ro vẫn khác nhau tùy theo thiết lập hostNetwork, hostPID, privileged, allowPrivilegeEscalation, seccomp, capability. PSS gom các thuộc tính runtime này thành hồ sơ chuẩn để tạo ra tiêu chuẩn tối thiểu của tổ chức.

Thứ hai, trong cụm đa thuê bao (multi-tenant), phải bảo đảm YAML do các nhóm phát triển tạo ra không vượt qua ranh giới nền tảng. Khi gắn hồ sơ vào namespace, dù pipeline triển khai của từng nhóm khác nhau vẫn phải vượt qua cùng một tiêu chuẩn admission, nhờ đó kiểm tra bảo mật không phụ thuộc vào trí nhớ của lập trình viên ứng dụng.

Thứ ba, nếu ngay từ đầu từ chối theo tiêu chuẩn restricted, các workload và công cụ vận hành hiện có có thể bị dừng đồng loạt. warn và audit của PSA là giai đoạn đệm cho phép triển khai trong khi vẫn quan sát vi phạm. Cần tận dụng điều này để giảm ngoại lệ và chỉ cho phép namespace đặc quyền một cách tường minh khi thật sự cần thiết.

2. Hồ sơ PSS và ranh giới bảo mật

flowchart LR
    P[Pod manifest] --> PSA[Pod Security Admission]
    PSA --> L{Namespace labels}
    L --> PR[Privileged<br/>unrestricted]
    L --> BA[Baseline<br/>known escalation prevention]
    L --> RE[Restricted<br/>hardening best practices]
    PR --> A[Pod admitted]
    BA --> B[Baseline-compliant Pod]
    RE --> C[Restricted-compliant Pod]
    PSA --> M{Mode}
    M --> E[enforce: reject]
    M --> U[audit: audit annotation]
    M --> W[warn: client warning]

Ba mức của PSS không phải là các lựa chọn độc lập mà là những ranh giới tích lũy. privileged là hồ sơ không có giới hạn, baseline ngăn chặn các con đường leo thang đặc quyền đã biết nhưng coi trọng khả năng tương thích với việc chạy container thông thường. restricted bao gồm các ràng buộc của baseline và yêu cầu thêm các thực hành gia cố Pod hiện hành như non-root, seccomp, tối thiểu hóa capability.

privileged có thể là không thể tránh khỏi đối với các workload nền tảng cần tương tác trực tiếp với máy chủ như node agent, device plugin, hệ thống mạng/lưu trữ. Tuy nhiên, nếu vì tiện lợi mà chạy mọi công cụ vận hành ở chế độ privileged thì ý nghĩa của cô lập namespace sẽ mất đi. Hồ sơ này phải giới hạn cho chủ thể vận hành đáng tin cậy và namespace hẹp, đồng thời tài liệu hóa lý do cho phép, image, service account và phạm vi node.

baseline là điểm xuất phát thực tế cho ứng dụng thông thường. Nó hạn chế các rủi ro đã biết như chia sẻ host namespace, container privileged, capability bổ sung nguy hiểm, hostPath, hostPort, sysctl không được phép. Chỉ cần một container vi phạm tiêu chuẩn là toàn bộ Pod không qua được kiểm tra, nên phải rà soát cả init container và ephemeral container.

restricted hy sinh một phần khả năng tương thích để áp dụng gia cố Pod mạnh mẽ. Container Linux không được cho phép privilege escalation, seccomp phải chỉ định là RuntimeDefault hoặc Localhost, capability phải loại bỏ ALL và chỉ thêm lại NET_BIND_SERVICE khi cần. Nếu container và image không chạy dưới dạng non-root thì cần sửa đổi ứng dụng.

Hồ sơ	Mục đích	Đối tượng thông thường	Kiểm soát tiêu biểu
Privileged	Tương thích và quyền hạn tối đa	Workload vận hành node, hạ tầng	Không giới hạn, bắt buộc có lý do ngoại lệ
Baseline	Chặn leo thang đặc quyền đã biết	Ứng dụng thông thường	Hạn chế host namespace, privileged, capability nguy hiểm
Restricted	Gia cố Pod mạnh mẽ	Workload quan trọng về bảo mật, độ tin cậy thấp	non-root, seccomp, tối thiểu hóa capability

Chỉ gắn tên hồ sơ vào namespace không có nghĩa là bảo mật đã hoàn tất. Ví dụ, baseline không kiểm tra image có lỗ hổng, và restricted cũng không kiểm soát mục đích sử dụng token của service account hay di chuyển ngang (east-west) trong mạng. PSS cần được hiểu là tuyến phòng thủ đầu tiên xử lý câu hỏi "Pod có thể khởi động với quyền hạn nào".

3. Cơ chế hoạt động của PSA và mô hình nhãn

sequenceDiagram
    participant C as Client or Controller
    participant API as kube-apiserver
    participant PSA as Pod Security Admission
    participant NS as Namespace labels
    participant AUD as Audit log
    participant K as Kubelet
    C->>API: Create Deployment or Pod
    API->>PSA: Admission request
    PSA->>NS: Read enforce/audit/warn level and version
    PSA-->>API: Decision and warnings
    PSA->>AUD: Record violation annotation when audit applies
    API-->>C: Reject, warning, or success
    API->>K: Schedule admitted Pod

PSA đọc nhãn namespace để xác định hồ sơ cho từng chế độ. Định dạng cơ bản là pod-security.kubernetes.io/<MODE>: <LEVEL>, trong đó MODE là một trong enforce, audit, warn, còn LEVEL là một trong privileged, baseline, restricted. Ví dụ, pod-security.kubernetes.io/enforce=baseline từ chối tạo Pod vi phạm baseline.

enforce xử lý vi phạm như một yêu cầu API thất bại. Người dùng nhận Forbidden kèm thông tin trường nào vi phạm tiêu chuẩn và phải sửa manifest. Khi tạo Deployment, dù template chưa trở thành Pod ngay, cần phân biệt rằng cảnh báo kiểm tra template được xem xét trong pipeline, còn enforcement được áp dụng khi Pod thực sự được tạo.

audit cho phép yêu cầu nhưng để lại audit annotation để có thể tổng hợp vi phạm trong log kiểm toán tập trung. Nó hữu ích khi nhóm vận hành cần nắm bắt bằng số liệu "ở namespace nào, kiểm soát nào bị vi phạm bao nhiêu lần". Nếu việc thu thập log bị bỏ sót, audit sẽ biến thành sự cho phép âm thầm, nên phải thiết kế đồng thời chính sách kiểm toán của API server và thời hạn lưu giữ log.

warn cho phép yêu cầu nhưng trả về cảnh báo hướng tới người dùng cho client. Ưu điểm là lập trình viên và pipeline triển khai có thể thấy ngay, nhưng nếu công cụ tự động hóa bỏ qua cảnh báo thì sẽ không dẫn tới cải thiện. Cần có quy tắc vận hành chuyển warning trong CI thành lỗi hoặc hạng mục công việc.

Ba chế độ có thể được thiết lập đồng thời với các mức khác nhau. Ví dụ, thiết lập enforce=baseline, audit=restricted, warn=restricted sẽ cưỡng chế baseline và quan sát trạng thái sẵn sàng chuyển sang restricted. Trong môi trường production, có thể dùng tổ hợp này để giảm dần vi phạm đối với mức mục tiêu mạnh hơn trong khi vẫn giữ được tính sẵn sàng.

3.1 Cố định phiên bản chính sách

Tiêu chuẩn của PSS có thể thay đổi theo phiên bản minor của Kubernetes. Dùng nhãn pod-security.kubernetes.io/<MODE>-version có thể cố định tiêu chuẩn của một phiên bản cụ thể, còn dùng latest thì theo tiêu chuẩn tài liệu hiện tại. Để tránh tiêu chuẩn đột ngột bị siết chặt khi nâng cấp cụm, nên xem xét cách cố định enforcement ở phiên bản đã kiểm chứng và vận hành audit, warn theo tiêu chuẩn mới nhất.

Cố định phiên bản không phải là giấy phép để duy trì bảo mật ở mức thấp mãi mãi. Phải trực quan hóa bằng audit và warn các trường được phép ở phiên bản cố định nhưng bị hạn chế ở tiêu chuẩn mới nhất, lập kế hoạch sửa ứng dụng và nâng tiêu chuẩn trước lần nâng cấp tiếp theo. Đặc biệt, với cụm hỗn hợp phiên bản mà kubelet cũ chưa thực thi đầy đủ trường Pod OS, cần thận trọng khi chọn phiên bản Restricted.

4. Các hạng mục kiểm soát chính và quy trình áp dụng

4.1 Cô lập máy chủ và leo thang đặc quyền

Khi dùng hostNetwork, hostPID, hostIPC, Pod gắn kết với vùng mạng, tiến trình, IPC của node. Nguyên tắc là không cho phép các trường này ngoại trừ các Pod hệ thống có mục đích rõ ràng như giám sát hay plugin mạng. Ngay cả khi cần host namespace, vẫn phải phân tích các workload khác có thể được đặt trên cùng node và các đường tấn công.

Container privileged có thể vượt qua hầu hết các cơ chế cô lập container. Nếu allowPrivilegeEscalation là true, tiến trình đang chạy có thể mở rộng quyền thông qua setuid hoặc file capability, nên restricted yêu cầu giá trị này là false. Nếu runAsNonRoot và runAsUser không khớp với ID người dùng thực tế của image thì dịch vụ có thể không khởi động được, vì vậy việc định nghĩa người dùng ở giai đoạn build image là rất quan trọng.

Linux capability nhỏ hơn toàn quyền root, nhưng các quyền có thể ảnh hưởng đến hệ thống như NET_ADMIN, SYS_ADMIN làm bề mặt tấn công lớn hơn nhiều. Trong restricted, dùng mẫu loại bỏ mọi capability rồi chỉ thêm NET_BIND_SERVICE khi thật sự cần. Đổi ứng dụng sang dùng cổng cao có thể an toàn hơn việc duy trì ngoại lệ capability.

4.2 seccomp, AppArmor, SELinux

seccomp giới hạn các system call mà tiến trình container có thể gọi. RuntimeDefault dùng hồ sơ mặc định do runtime cung cấp, còn ứng dụng đặc thù có thể chỉ định hồ sơ Localhost. Nếu né tránh bằng privileged mà không có hồ sơ thì sự cố có thể giảm nhưng bề mặt tấn công kernel mở rộng, nên phải kiểm thử hiệu năng và tương thích để chỉ cho phép các system call cần thiết.

AppArmor và SELinux phụ thuộc vào chính sách của image và hệ điều hành node. Dù PSS kiểm tra dạng cho phép của một trường cụ thể, vẫn phải xác minh riêng xem hồ sơ đã được nạp trên node thực tế hay chưa và sự kiện kiểm toán có được thu thập hay không. Khi trộn lẫn các hệ điều hành node khác nhau, cùng một Pod có thể hoạt động khác nhau do khác biệt hồ sơ bảo mật.

4.3 Thiết kế YAML và liên kết chuỗi cung ứng

Việc qua được PSS hay không được đánh giá dựa trên PodSpec cuối cùng, nên phải kiểm tra tất cả giá trị mặc định của Helm, overlay của Kustomize và template do Operator sinh ra. Dù Deployment do lập trình viên viết là an toàn, nếu Operator thêm init container privileged thì kết quả triển khai sẽ khác. Vì vậy, thực hiện server dry-run và kiểm tra chính sách trên manifest đã được render.

Chữ ký image và SBOM không thay thế được PSS. Chữ ký giải thích image nào đã được triển khai, SBOM giải thích bên trong có những thành phần nào, còn PSS giải thích image đó chạy với quyền hạn nào. Kết hợp ba tín hiệu này vào một chính sách phê duyệt triển khai duy nhất có thể đồng thời giảm image có lỗ hổng và quyền runtime quá mức.

4.4 Miễn trừ cho workload có đặc quyền

PSA có thể cấu hình tên người dùng, RuntimeClass, namespace thành danh sách miễn trừ tường minh. Yêu cầu được miễn trừ sẽ bỏ qua cả enforce, audit, warn, nên miễn trừ trên diện rộng thực chất là né tránh chính sách. Khi miễn trừ một service account, phải kiểm tra xem những người dùng có thể tạo Deployment bằng service account đó có gián tiếp được miễn trừ hay không.

Miễn trừ phải được phê duyệt dựa trên chức năng cụ thể và biện pháp kiểm soát, chứ không phải "vì đó là hệ thống". Ví dụ, cố định namespace của plugin mạng, RuntimeClass của device plugin, image digest và node thực thi của công cụ chẩn đoán node, đồng thời bổ sung RBAC, NetworkPolicy, log kiểm toán. Định kỳ rà soát lại danh sách miễn trừ để không còn sót lại quyền hạn không còn cần thiết.

5. Quy trình áp dụng và vận hành

Bước đầu tiên là lập danh mục mọi namespace và workload. Phân loại namespace hệ thống, công cụ build/triển khai, ứng dụng, agent quan sát/bảo mật và thu thập hiện trạng sử dụng privileged, hostPath, hostNetwork, capability. Namespace chưa có nhãn phải được coi là "chưa được đánh giá" chứ không phải "an toàn".

Thứ hai, xác định mức mục tiêu và bật warn và audit trước. Ví dụ, namespace phát triển cảnh báo theo baseline, còn dịch vụ nhạy cảm cảnh báo và kiểm toán theo restricted. Quản lý trường vi phạm, nhóm sở hữu, độ khó sửa, mức ảnh hưởng nghiệp vụ bằng bảng, nhưng cải tiến thực tế được ghi lại bằng runbook dạng văn xuôi giải thích nguyên nhân và phương án thay thế.

Thứ ba, áp dụng enforce ở môi trường kiểm thử và staging. Dùng kubectl label --dry-run=server để đối chiếu các Pod hiện có với tiêu chuẩn mới, và xác minh cả các Pod do Deployment, Job, CronJob, Operator tạo ra. Việc vượt qua các kịch bản vận hành bao gồm rolling update, khôi phục sự cố, ephemeral container để debug, thay thế node quan trọng hơn một lần triển khai thành công.

Thứ tư, production chuyển đổi dần theo từng namespace. Ứng dụng cơ bản ưu tiên áp dụng baseline enforcement, và các dịch vụ đã sửa xong được nâng lên restricted. Các workload privileged không thể tránh được cô lập bằng namespace riêng và miễn trừ đã phê duyệt, không trộn lẫn với ứng dụng thông thường.

Thứ năm, quan sát khác biệt tiêu chuẩn trước và sau nâng cấp. Nếu đã cố định phiên bản enforcement, tiếp tục đánh giá tiêu chuẩn mới nhất bằng audit, warn và đưa các thay đổi của phiên bản Kubernetes mới vào hạng mục kiểm chứng phát hành. Liên kết số vi phạm chính sách, số miễn trừ, tỷ lệ triển khai thất bại, thời gian phát hiện sự cố bảo mật với dashboard và chỉ số quản trị.

6. Phân tích so sánh

6.1 PSS và công cụ chính sách đa năng

PSS được tích hợp sẵn trong Kubernetes và cung cấp mô hình vận hành đơn giản gồm ba hồ sơ và nhãn namespace. Ít webhook riêng phải cài đặt và nâng cấp, có lợi cho việc áp dụng nhanh tuyến bảo mật cơ bản. Ngược lại, khó biểu diễn các chính sách chi tiết như registry image riêng của tổ chức, tiền tố registry được phép, đường dẫn hostPath, điều kiện giữa các trường.

Các công cụ đa năng như OPA Gatekeeper hay Kyverno có thể mở rộng chính sách thành quy tắc của tổ chức và cung cấp kiểm toán, biến đổi (mutation), chuyển đổi tự động. Đổi lại, phải vận hành tính sẵn sàng của webhook, thứ tự chính sách, hiệu năng, hành vi khi thất bại và vòng đời CRD. Trong thực tế, tổ hợp hợp lý là dùng PSS để cưỡng chế tuyến tối thiểu chung và dùng công cụ đa năng bổ sung các điều kiện riêng của doanh nghiệp.

Trục so sánh	PSS, PSA	Công cụ chính sách đa năng
Cài đặt	Chủ yếu là chức năng tích hợp của Kubernetes	Cần controller, webhook riêng
Biểu diễn chính sách	Ba hồ sơ và các trường bảo mật Pod	Mở rộng điều kiện, chuyển đổi, kiểm tra theo tổ chức
Phạm vi áp dụng	Chủ yếu là bảo mật Pod và namespace	Rộng, gồm image, nhãn, quan hệ tài nguyên
Ưu điểm	Đơn giản, nhất quán, rào cản áp dụng thấp	Khả năng biểu diễn cao, tự động hóa
Lưu ý	Hạn chế về ngoại lệ chi tiết và quy tắc doanh nghiệp	Tính sẵn sàng webhook, xung đột chính sách, phức tạp vận hành

6.2 PSS và bảo mật runtime

PSS là kiểm soát phòng ngừa tại thời điểm tạo hoặc thay đổi Pod. Các công cụ runtime như Falco quan sát tiến trình đang chạy, truy cập tệp, hành vi mạng để phát hiện tấn công đã vượt qua chính sách hoặc hành vi bất thường đã được thực thi. Cái trước là "không cho khởi động với thiết lập này", cái sau là "phát hiện hành vi bất thường sau khi khởi động", nên đây không phải quan hệ cạnh tranh mà là quan hệ phòng thủ theo chiều sâu.

Ví dụ, nếu một image đã qua restricted bị khai thác lỗ hổng ứng dụng để chạy shell từ tiến trình bình thường thì chỉ PSS không thể phát hiện. Ngược lại, nếu chỉ dựa vào phát hiện runtime thì chỉ ứng phó được sau khi tấn công đã diễn ra. Phải vận hành đồng thời chính sách tạo Pod, cô lập mạng, tin cậy image và phát hiện runtime.

7. Tình huống áp dụng và chuyên sâu

7.1 Cụm API giao dịch tài chính

API giao dịch tài chính đặt mục tiêu là restricted và bắt đầu với enforce=baseline, audit=restricted, warn=restricted. Nhóm phát triển hỗ trợ người dùng non-root và read-only root filesystem trong image, còn nhóm nền tảng đưa seccomp RuntimeDefault và capability drop vào Helm chart chung. Log kiểm toán theo dõi vi phạm theo dịch vụ và các miễn trừ đã phê duyệt.

Sau khi bật restricted enforcement ở staging, lặp lại phê duyệt thanh toán, rolling deploy, khôi phục sự cố. Nếu cần ephemeral container tạm thời để debug, thay vì cấp quyền unrestricted cho người vận hành thông thường, hãy dùng RuntimeClass debug đã phê duyệt và tài khoản truy cập có TTL ngắn. Như vậy sự tiện lợi khi ứng phó sự cố sẽ không bị đóng cứng thành đường privileged lâu dài.

7.2 Cụm edge sản xuất

Tại node edge của nhà máy, device plugin và network agent có thể yêu cầu host namespace hoặc capability cụ thể. Tách chúng khỏi namespace ứng dụng và thu hẹp đối tượng miễn trừ theo image digest, RuntimeClass, service account. Dịch vụ thu thập cảm biến được vận hành ở baseline hoặc restricted để đường đặc quyền của thiết bị hiện trường không lan sang API nghiệp vụ.

Cụm edge có kết nối không ổn định nên cập nhật chính sách trung tâm có thể bị chậm; vì vậy khai báo nhãn và thiết lập PSA ngay ở giai đoạn cấp phát cụm và lưu giữ log audit cục bộ. Khi kết nối lại với trung tâm, đồng bộ danh sách miễn trừ và sự kiện vi phạm để ngoại lệ theo từng hiện trường không bị tích lũy.

7.3 Chiến lược bài làm liên kết đề thi trước

Trong bài thi, thay vì chỉ viết định nghĩa PSS, nên trình bày bằng sơ đồ khái niệm luồng nhân quả "PodSpec nguy hiểm → PSA phán định theo chế độ → phản hồi API hoặc kiểm toán → kubelet thực thi → quan sát runtime". Sau đó tóm tắt ba hồ sơ bằng bảng và giải thích bằng văn xuôi lý do mang tính tổ chức khiến mỗi hồ sơ là cần thiết.

Khi liên kết với các chủ đề tương tự như bảo mật container, DevSecOps, zero trust, bảo mật chuỗi cung ứng, cần phân biệt thời điểm kiểm soát. PSS xử lý quyền của workload, chữ ký image xử lý nguồn gốc, SBOM xử lý tính minh bạch của thành phần, NetworkPolicy xử lý phạm vi truyền thông, bảo mật runtime xử lý hành vi. Trình bày được sự phân biệt này sẽ tránh được bài làm kiểu liệt kê "cài thật nhiều công cụ bảo mật".

8. Những điểm cần cân nhắc và hàm ý

Phải thiết kế cân bằng giữa tính sẵn sàng và đặc quyền tối thiểu. Cưỡng chế Restricted ngay lập tức vô điều kiện có thể làm dừng công cụ vận hành và triển khai, nên cần thu thập vi phạm bằng warn, audit và xác định thứ tự sửa theo dịch vụ. Ngược lại, cho phép privileged như giá trị mặc định sẽ mở rộng phạm vi sự cố, nên ngoại lệ phải được kiểm soát bằng namespace riêng, RBAC, kiểm toán và ngày hết hạn.
Phải quản lý đồng thời phiên bản chính sách và phiên bản cụm. Nâng cấp Kubernetes có thể làm thay đổi tiêu chuẩn PSS, và kubelet hỗn hợp phiên bản có thể thực thi các trường theo OS khác nhau. Phiên bản enforcement cần được kiểm chứng trước, còn audit, warn vận hành theo tiêu chuẩn mới nhất để phát hiện sớm rủi ro của lần nâng cấp tiếp theo.
Phải quản lý miễn trừ như tài sản bảo mật. Miễn trừ theo người dùng, RuntimeClass, namespace bỏ qua cả ba chế độ, nên phải đăng ký lý do, chủ sở hữu, image, node được phép và ngày hết hạn. Rà soát cả các tài nguyên cấp dưới mà service account được miễn trừ có thể tạo ra và thực hiện tái chứng nhận quyền truy cập định kỳ.
Phải liên kết rõ ràng các kiểm soát nằm ngoài PSS. Dù đã qua PSS, vẫn có thể còn image có lỗ hổng, truy cập mạng quá mức, service account bị chiếm đoạt, hành vi bất thường runtime. Liên kết quét và ký image, SBOM/VEX, NetworkPolicy, quản lý Secret, phát hiện runtime vào luồng chính sách và xác định chủ sở hữu của từng kiểm soát.
Phải kiểm chứng hiệu quả chính sách bằng chỉ số vận hành. Mục tiêu không chỉ là giảm số vi phạm mà phải theo dõi đồng thời tỷ lệ privileged, tỷ lệ miễn trừ, tỷ lệ triển khai thất bại, tuổi thọ trung bình của ngoại lệ chính sách, thời gian phát hiện sự cố. Có các chỉ số này mới giải thích được từ góc nhìn Kỹ sư chuyên nghiệp ảnh hưởng của việc tăng cường bảo mật lên năng suất phát triển và tính sẵn sàng.

Tài liệu tham khảo

Tóm tắt một câu: PSS định nghĩa tuyến bảo mật tối thiểu cho quyền của Pod và PSA áp dụng dần tiêu chuẩn đó theo warn, audit, enforce cho từng namespace, vì vậy phải thiết kế đồng thời các kiểm soát về phiên bản, miễn trừ, chuỗi cung ứng và runtime thì bảo mật container mới thực sự hiệu quả.