Chương 17: GKE Multi-Tenancy & Workload Isolation
Tại sao chương này quan trọng
Multi-tenancy là một trong những quyết định kiến trúc tốn kém nhất nếu làm sai và tiết kiệm nhất nếu làm đúng. Mỗi GKE cluster có chi phí cố định: control plane, node tối thiểu, system DaemonSets, monitoring agents, mạng lưới. Khi một tổ chức có 50 đội phát triển, lựa chọn giữa "50 cluster" và "1 cluster với 50 namespace" tạo ra khác biệt hàng trăm nghìn đô la mỗi năm — nhưng cũng tạo ra khác biệt về blast radius khi có sự cố bảo mật.
Vấn đề cốt lõi: Kubernetes không được thiết kế như một hệ thống multi-tenant thực thụ ngay từ đầu. Namespace là ranh giới tổ chức (organizational), không phải ranh giới bảo mật (security) mạnh như VM hay project. Control plane (API server, etcd, scheduler, controllers) được chia sẻ giữa tất cả tenant. Kernel của node được chia sẻ giữa tất cả Pod trên node đó. Mỗi lớp chia sẻ này là một mặt phẳng tấn công (attack surface) tiềm năng.
Theo tài liệu GKE multi-tenancy, mục tiêu của isolation là "giảm thiểu thiệt hại mà một tenant bị xâm phạm hoặc độc hại có thể gây ra cho cluster và các tenant khác". Chương này không dạy bạn cách tạo namespace — nó dạy bạn hiểu ranh giới thực sự nằm ở đâu, lớp isolation nào đủ mạnh cho mức độ tin cậy nào, và cách kết hợp các cơ chế thành một mô hình phòng thủ nhiều lớp (defense-in-depth) phù hợp với threat model của bạn.
Điều kiện tiên quyết
- Chương 8: GKE Scheduler — resource model, requests/limits, node affinity/taints/tolerations
- Chương 10: GKE Admission Control & Policy — admission webhooks, policy enforcement điểm chặn
- Chương 12: GKE Security — mô hình shared responsibility, các lớp phòng thủ, threat model
Mental model: isolation là một phổ, không phải nhị phân
Sai lầm phổ biến nhất là tư duy "có isolation" hoặc "không có isolation". Thực tế, isolation tồn tại trên một phổ liên tục, mỗi mức tốn thêm chi phí (tiền bạc, vận hành, độ phức tạp) để đổi lấy ranh giới mạnh hơn:
Yếu hơn ──────────────────────────────────────────────► Mạnh hơn
Rẻ hơn ──────────────────────────────────────────────► Đắt hơn
Namespace RBAC + Node pool GKE Sole-tenant Separate
(logical) NetworkPol riêng Sandbox nodes cluster
ResourceQ (taint) (gVisor) (hardware) (control plane)
+PSA
│ │ │ │ │
soft multi-tenancy ───┴───────────┤ ────────hard multi-tenancy────────►
│
ranh giới kernel/hardwareHai câu hỏi quyết định bạn cần ở đâu trên phổ này:
- Mức độ tin cậy giữa các tenant: Tenant là các đội nội bộ (trusted) hay khách hàng bên ngoài chạy code tùy ý (untrusted)? Đây là yếu tố quyết định số một.
- Yêu cầu tuân thủ: PCI-DSS, HIPAA, FedRAMP có thể yêu cầu hardware-level isolation bất kể mức độ tin cậy.
Tài liệu GKE xác định năm cấp độ isolation: cluster, namespace, node, Pod, và container. Phần lớn pattern multi-tenancy xoay quanh việc kết hợp các cơ chế namespace-scoped với các cơ chế node-level và kernel-level.
Cấu trúc chương
| File | Chủ đề |
|---|---|
| 01. Multi-Tenancy Models | Soft vs hard tenancy, mô hình tin cậy, khi nào chọn cluster riêng |
| 02. Namespace Isolation & HNC | Shared vs isolated resources, Hierarchical Namespace Controller, policy propagation |
| 03. RBAC cho Multi-Tenancy | Role vs ClusterRole, impersonation risks, escalation paths, least privilege |
| 04. NetworkPolicy Isolation | Default-deny, ingress/egress rules, Dataplane V2/Cilium, namespace selectors |
| 05. ResourceQuota & LimitRange | Fair allocation, default constraints, quota enforcement, noisy neighbor |
| 06. Pod Security Standards | Privileged/baseline/restricted, enforce/audit/warn, per-namespace labels |
| 07. GKE Sandbox (gVisor) | Kernel interception, Sentry/Gofer, use cases, overhead, limitations |
| 08. Node-Level Isolation | Dedicated node pools, taints/tolerations, sole-tenant nodes, HIPAA/PCI |
| 09. Multi-Tenant Operations | Per-namespace log routing, cost attribution, billing export BigQuery |
Lộ trình đọc đề xuất
Nếu bạn đang thiết kế một internal platform (tenant tin cậy): 01 → 02 → 03 → 05 → 09. Tập trung vào tổ chức namespace, RBAC sạch, fair allocation, và cost showback.
Nếu bạn đang xây SaaS multi-tenant (tenant untrusted): 01 → 04 → 06 → 07 → 08. Tập trung vào các ranh giới bảo mật mạnh: network isolation, Pod security, kernel sandbox, hardware isolation.
Nếu bạn cần tuân thủ (PCI/HIPAA): 01 → 08 → 06 → 04 → 09. Hardware isolation và audit trail là trọng tâm.
Nguyên tắc xuyên suốt chương
Namespace không phải là ranh giới bảo mật mạnh. Nó là điểm gắn cho các chính sách (RBAC, NetworkPolicy, ResourceQuota, PSA). Sức mạnh isolation đến từ các chính sách bạn gắn lên đó, không phải từ bản thân namespace.
Taint/toleration và Pod anti-affinity có thể bị bỏ qua bởi tenant độc hại. Tài liệu GKE cảnh báo rõ các cơ chế này chỉ dùng được với tenant tin cậy không có quyền truy cập trực tiếp vào control plane. Đừng nhầm "scheduling hint" với "security control".
Defense-in-depth là bắt buộc, không phải tùy chọn. Không có cơ chế đơn lẻ nào đủ. Một SaaS untrusted cần đồng thời: namespace + RBAC + NetworkPolicy default-deny + ResourceQuota + restricted PSA + GKE Sandbox.
Khi nghi ngờ về untrusted code, hãy dùng cluster riêng. Đây là ranh giới mạnh nhất và đơn giản nhất để lý luận về bảo mật. Soft multi-tenancy là tối ưu hóa chi phí, không phải mặc định bảo mật.