My Awesome Project

Appearance

Pod Security Standards per Namespace ​

Tại sao Pod Security là lớp phòng thủ không thể thiếu ​

NetworkPolicy kiểm soát luồng mạng, RBAC kiểm soát quyền API, ResourceQuota kiểm soát tài nguyên — nhưng không cơ chế nào trong số đó ngăn một tenant tạo một Pod privileged để thoát khỏi container và chiếm node. Một Pod với privileged: true, hoặc mount hostPath: /, hoặc dùng hostNetwork/hostPID, về cơ bản có quyền root trên node — và do đó truy cập mọi Pod, mọi Secret, mọi tenant trên node đó.

Đây là lý do Pod Security là lớp phòng thủ cốt lõi: nó kiểm soát Pod được phép yêu cầu những đặc quyền gì. Trong multi-tenant, một tenant không nên được tạo Pod phá vỡ ranh giới container. Pod Security Standards (PSS) định nghĩa các mức đặc quyền, và Pod Security Admission (PSA) — controller tích hợp sẵn trong Kubernetes/GKE — thực thi chúng theo từng namespace, khiến nó hoàn hảo cho mô hình per-tenant.

Internal model: ba level, ba mode ​

Theo tài liệu GKE, Pod Security Admission có hai trục độc lập: level (mức độ hạn chế) và mode (cách phản ứng khi vi phạm).

Ba level (Pod Security Standards) ​

LevelMô tảDùng cho
privilegedKhông hạn chế, cho phép mọi privilege escalation đã biếtSystem workloads, trusted infra
baselineHạn chế tối thiểu, ngăn các privilege escalation đã biết, cho phép cấu hình Pod mặc địnhTenant bán tin cậy
restrictedHạn chế mạnh, tuân theo best practice hardening PodTenant untrusted, workload nhạy cảm

baseline chặn: hostNetwork, hostPID, hostIPC, hostPath volumes, privileged containers, host ports (phần lớn), thêm capabilities ngoài tập mặc định.

restricted chặn mọi thứ baseline chặn, cộng thêm yêu cầu:

  • allowPrivilegeEscalation: false
  • capabilities.drop: ["ALL"] (drop mọi Linux capability)
  • runAsNonRoot: true (không chạy bằng root)
  • seccompProfile.type phải là RuntimeDefault hoặc Localhost
  • volume types bị giới hạn

Ba mode ​

ModeHành vi khi vi phạm
enforceTừ chối tạo Pod. Thêm audit event vào audit log.
auditCho phép tạo Pod, nhưng ghi audit event.
warnCho phép tạo Pod, hiển thị cảnh báo cho user.

Sức mạnh của thiết kế này: bạn có thể chạy nhiều mode cùng lúc ở các level khác nhau trên cùng namespace. Pattern chuẩn để rollout an toàn: enforce=baseline (chặn cứng mức cơ bản) đồng thời warn=restricted + audit=restricted (cảnh báo và ghi log nếu chưa đạt restricted, nhưng chưa chặn) — cho phép tenant thấy họ cần sửa gì trước khi nâng enforce lên restricted.

Áp dụng per-namespace bằng label ​

PSA được cấu hình hoàn toàn qua label trên namespace — không cần CRD, không cần controller riêng. Đây là điểm khiến nó lý tưởng cho multi-tenancy:

yaml
apiVersion: v1
kind: Namespace
metadata:
  name: tenant-untrusted
  labels:
    # enforce restricted — chặn Pod vi phạm
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    # audit + warn cũng restricted để có log/cảnh báo đầy đủ
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Cú pháp label: pod-security.kubernetes.io/<mode>: <level>. Mỗi namespace tenant nhận bộ label phù hợp với mức tin cậy của tenant đó. Đây là cơ chế per-tenant tự nhiên: namespace tin cậy có thể baseline, namespace untrusted có restricted.

Chiến lược rollout an toàn ​

Đừng bao giờ bật thẳng enforce=restricted lên namespace đang chạy — sẽ phá vỡ workload không tuân thủ. Thay vào đó:

yaml
# Giai đoạn 1: chỉ quan sát
pod-security.kubernetes.io/warn: restricted
pod-security.kubernetes.io/audit: restricted
# (chưa có enforce — không Pod nào bị chặn, nhưng thấy ai vi phạm)

Quan sát audit log/warning vài tuần, sửa workload vi phạm, rồi mới:

yaml
# Giai đoạn 2: enforce
pod-security.kubernetes.io/enforce: restricted

Giới hạn của PSA và khi nào cần policy engine ​

PSA mạnh nhưng cố ý đơn giản. Nó chỉ có ba level cố định, không tùy chỉnh được. Các giới hạn quan trọng:

  1. Không tùy biến rule. Bạn không thể nói "restricted nhưng cho phép một hostPath cụ thể". Chỉ ba level dựng sẵn. Nếu cần policy tinh chỉnh, dùng Policy Controller (Gatekeeper/OPA) hoặc Kyverno — chúng cho phép viết constraint tùy ý (xem Chương 10).

  2. Không kiểm soát các khía cạnh ngoài Pod security context. PSA không quản lý label bắt buộc, registry cho phép, resource limits, v.v. Đó là việc của policy engine.

  3. GKE Autopilot ghi đè. Theo tài liệu GKE, "bạn không thể tạo policy ghi đè built-in security settings trong GKE Autopilot" — Autopilot đã enforce một baseline security riêng (xem Chương 16). PSA bổ sung chứ không thay thế.

  4. GKE bỏ qua policy trên kube-system (từ phiên bản 1.23.6-gke.1900+) để tránh chặn system workload.

Quan hệ thực tế: PSA là baseline phòng thủ rẻ, không cần cài đặt. Policy Controller/Kyverno là lớp tùy chỉnh sâu. Trong multi-tenant production nghiêm túc, thường dùng cả hai: PSA cho restricted baseline trên mọi namespace tenant, policy engine cho các rule tổ chức cụ thể.

Production architecture patterns ​

Pattern 1: Restricted mặc định cho mọi tenant namespace ​

Mọi namespace tenant được tạo với enforce=restricted ngay từ đầu (qua template/GitOps). Tenant nào cần đặc quyền cao hơn phải xin ngoại lệ tường minh (chuyển sang baseline cho namespace cụ thể, với phê duyệt). Đây là zero-trust: hạn chế tối đa là mặc định, nới lỏng là ngoại lệ có kiểm soát.

Pattern 2: Level phân tầng theo tin cậy ​

namespace system/platform:    privileged  (trusted infra)
namespace internal-teams:     baseline    (trusted, cần một số capability)
namespace customer-workloads: restricted  (untrusted)

Map level PSA với mức tin cậy đã xác định ở file 01. Mỗi tầng tin cậy có baseline security tương ứng.

Pattern 3: PSA + Policy Controller kết hợp ​

PSA enforce restricted (rẻ, không cần cài), Policy Controller thêm các constraint không thuộc phạm vi PSA: chỉ cho phép image từ Artifact Registry nội bộ, bắt buộc label cost-center, chặn LoadBalancer Service ngoài allowlist. Hai lớp bổ sung nhau, không trùng lặp.

Real-world scenario ​

SaaS chạy plugin của khách hàng: Khách hàng upload container plugin chạy trong namespace riêng của họ. Mọi namespace khách hàng có enforce=restricted: plugin không thể chạy root, không drop được privilege escalation, mọi capability bị drop, seccomp RuntimeDefault bắt buộc. Kết hợp với GKE Sandbox (file 07), một plugin độc hại cố thoát container bị chặn ở hai lớp: PSA ngăn nó yêu cầu đặc quyền nguy hiểm ngay từ admission, và gVisor cô lập kernel cho phần còn lại. Policy Controller thêm constraint chặn image ngoài registry đã scan.

Common mistakes / anti-patterns ​

Anti-pattern 1: Bật enforce=restricted thẳng lên production ​

Vì sao xảy ra: Muốn bảo mật ngay, áp enforce mà không qua warn/audit.

Hệ quả ở scale: Mọi workload không tuân thủ (chạy root, thiếu seccomp profile, có capability dư) đột ngột bị từ chối khi redeploy. Outage hàng loạt cho tenant. Đội phải gỡ enforce khẩn cấp, mất niềm tin vào PSA.

Cách phòng tránh: Luôn rollout qua warn + audit trước, quan sát, sửa, rồi mới enforce. Đặc biệt với namespace đang chạy.

Anti-pattern 2: Để namespace tenant không có PSA label ​

Vì sao xảy ra: Quên gắn label khi tạo namespace; namespace không label dùng mặc định cluster (thường privileged hoặc không hạn chế).

Hệ quả ở scale: Tenant trong namespace không label được tạo Pod privileged, mount hostPath, dùng hostNetwork — phá vỡ mọi isolation. Một namespace bị bỏ sót là một lỗ hổng toàn diện.

Cách phòng tránh: Cấu hình PSA cấp cluster với một level mặc định an toàn (AdmissionConfiguration đặt default level baseline/restricted), để namespace không label vẫn được bảo vệ. Hoặc dùng policy engine bắt buộc mọi namespace tenant phải có PSA label.

Anti-pattern 3: Nhầm PSA với giải pháp toàn diện ​

Vì sao xảy ra: Bật restricted PSA và nghĩ đã đủ bảo mật multi-tenant.

Hệ quả ở scale: PSA chỉ kiểm soát Pod security context. Nó không cô lập kernel (cần GKE Sandbox), không chặn mạng (cần NetworkPolicy), không giới hạn tài nguyên (cần Quota). Một CVE container escape vẫn vượt qua được restricted Pod nếu không có sandbox.

Cách phòng tránh: PSA là một lớp trong defense-in-depth. Với untrusted, kết hợp PSA + NetworkPolicy + Quota + GKE Sandbox + (lý tưởng) cluster/node riêng.

Anti-pattern 4: Bỏ qua warning, không bao giờ nâng lên enforce ​

Vì sao xảy ra: Bật warn=restricted rồi để đó vĩnh viễn; không ai sửa warning.

Hệ quả ở scale: warn không chặn gì — chỉ cảnh báo. Nếu không bao giờ chuyển sang enforce, bạn có cảm giác an toàn giả tạo nhưng thực tế không enforce gì. Tenant vẫn tạo được Pod privileged.

Cách phòng tránh: warn/audit là giai đoạn chuyển tiếp, có deadline. Đặt mục tiêu rõ ràng chuyển sang enforce sau khi sửa xong vi phạm.

References ​