Chương 12: GKE Security — Hardening, RBAC, Pod Security

Vì sao chương này quyết định ranh giới giữa "an toàn" và "bị chiếm quyền"

Bảo mật GKE không phải là một tính năng bạn bật lên — nó là một chuỗi các lớp phòng thủ độc lập (defense-in-depth), và đặc tính nguy hiểm nhất của nó là: chỉ cần một lớp cấu hình sai cũng đủ để vô hiệu hóa tất cả các lớp còn lại. Một cluster có Shielded nodes, Workload Identity, Network Policy default-deny, Binary Authorization đầy đủ — nhưng để lộ một ServiceAccount token với quyền cluster-admin qua một Pod public-facing — thì toàn bộ kiến trúc phòng thủ sụp đổ. Bảo mật ở đây là bài toán "mắt xích yếu nhất", không phải "tổng các biện pháp".

Đây là điểm khác biệt cốt lõi giữa security và các chương khác của handbook. Với storage hay networking, một sai lầm gây outage hoặc data loss — tệ, nhưng phạm vi giới hạn. Với security, một sai lầm tạo ra lateral movement: kẻ tấn công vào được một Pod, escape ra node, dùng node service account để gọi GCP API, leo thang đến project, rồi pivot sang toàn bộ tổ chức. Phạm vi thiệt hại không tuyến tính — nó là cấp số nhân theo mức độ kết nối của hệ thống.

Ba kiểu thất bại bảo mật phổ biến nhất ở quy mô production, và cả ba đều bắt nguồn từ hiểu sai mô hình phân tầng:

Nhầm authentication với authorization. Đội ngũ tin rằng "đã đăng nhập bằng Google identity nghĩa là an toàn". Nhưng IAM chỉ trả lời câu hỏi "ai được phép kết nối tới cluster"; còn "kết nối rồi thì làm được gì" là việc của Kubernetes RBAC. Hai cổng này độc lập, và việc cấp roles/container.admin ở tầng IAM thực chất bypass toàn bộ RBAC vì nó ánh xạ ngầm sang cluster-admin. Hiểu sai ranh giới IAM ↔ RBAC là nguồn gốc của hầu hết privilege escalation trong GKE.
Tin rằng container là một security boundary. Container chia sẻ kernel với host. Một lỗ hổng kernel (container escape) biến một Pod compromise thành một node compromise. Đội ngũ chạy untrusted code, third-party image, hoặc multi-tenant workload mà không có sandbox (gVisor) hay node isolation — và một CVE kernel duy nhất phá vỡ toàn bộ sự cô lập giữa các tenant. Container là một resource boundary, không phải một security boundary mặc định.
Để lộ con đường từ workload đến GCP API. Đây là failure mode đắt giá nhất và khó thấy nhất. Node service account mặc định là Compute Engine default SA với scope rộng; metadata server của node để lộ token đó cho bất kỳ Pod nào không bị cô lập. Một Pod bị chiếm quyền curl metadata endpoint, lấy access token của node SA, và giờ kẻ tấn công có quyền của node trên toàn bộ project. Workload Identity tồn tại chính là để cắt đứt con đường này — nhưng chỉ khi metadata concealment được bật và node SA bị thu hẹp quyền.

Điểm mấu chốt mà chương này nhấn mạnh xuyên suốt: bảo mật GKE là một tập hợp các failure domain xếp lồng nhau, và mục tiêu của hardening là đảm bảo việc phá vỡ một domain không tự động phá vỡ domain bao quanh nó. Pod nằm trong node; node nằm trong cluster; cluster nằm trong project; project nằm trong organization. Mỗi ranh giới phải có một cơ chế cô lập riêng: securityContext + Pod Security cô lập Pod khỏi node; Shielded/Confidential/gVisor cô lập node khỏi node khác và khỏi host; RBAC + Network Policy cô lập trong cluster; IAM + Workload Identity cô lập cluster khỏi project. Hiểu đúng security nghĩa là biết mỗi cơ chế bảo vệ ranh giới nào, và điều gì xảy ra khi nó bị vượt qua.

Điều kiện tiên quyết

Chương 5 (GKE Control Plane Internals): bảo mật bắt đầu từ control plane. Phải hiểu API server, admission chain, etcd, và mô hình managed control plane của GKE để hiểu authentication flow, audit logging, và đâu là ranh giới shared responsibility giữa Google và bạn.
Chương 10 (GKE Admission Control & Policy): chương này đã trình bày sâu cơ chế của ValidatingAdmissionWebhook, MutatingAdmissionWebhook, Pod Security Admission, Gatekeeper/OPA và CEL policy. Chương 12 không lặp lại cơ chế đó — nó dùng admission control như một công cụ enforcement bảo mật và giả định bạn đã nắm pipeline. File 08 và 06 sẽ cross-reference Chương 10 liên tục.
IAM fundamentals: principal, role, policy binding, service account, các loại credential. Toàn bộ tầng authentication và Workload Identity xây trên nền IAM. Nếu chưa vững IAM, mô hình hai cổng IAM/RBAC sẽ khó hình dung.
Kubernetes security primitives: ServiceAccount, RBAC (Role/ClusterRole/Binding), securityContext, NetworkPolicy là vốn nền. Chương này đi sâu vào cơ chế và hệ quả production của chúng trên GKE, không dạy lại định nghĩa cơ bản.

Mức độ sâu

5/5 — Chương đi tới mức: mô hình token exchange ba bước của GKE metadata server và định danh principal principal://...workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/...; cơ chế ánh xạ ngầm giữa GKE IAM role và Kubernetes RBAC group (system:authenticated, các predefined ClusterRole); kiến trúc userspace-kernel của gVisor và danh sách syscall bị chặn; mô hình bộ nhớ mã hóa AMD SEV của Confidential nodes và lý do nó không bảo vệ data-in-transit; ngữ nghĩa ba cấp Privileged/Baseline/Restricted của Pod Security Standards ánh xạ xuống từng trường securityContext; mô hình eBPF của Dataplane V2 và FQDN-based egress policy; chuỗi attestation digest → attestor → note → policy của Binary Authorization và execution path qua admission controller; và bốn loại audit log (Admin Activity, Data Access, System Event, Policy Denied) với hệ quả chi phí và compliance của từng loại. Mọi tuyên bố kỹ thuật đối chiếu trực tiếp tài liệu Google Cloud và Kubernetes.

Cấu trúc chapter

1. Security Model & Shared Responsibility — Bản Đồ Phòng Thủ

Khung tư duy nền tảng: ai chịu trách nhiệm gì, và các lớp phòng thủ xếp như thế nào.

Mô hình shared responsibility: Google quản lý gì (control plane, etcd encryption, node OS patching khi auto-upgrade) vs customer quản lý gì (workload, RBAC, Network Policy, image security)
Khác biệt shared responsibility giữa GKE Standard và GKE Autopilot — Autopilot dịch chuyển ranh giới về phía Google
Defense-in-depth: bảy lớp phòng thủ từ organization → project → cluster → node → Pod → container → workload identity
Threat model GKE: container escape, lateral movement, credential theft, supply chain, misconfiguration
Vì sao "một lớp sai phá vỡ tất cả" và cách tư duy theo failure domain

2. Authentication & Identity — Mô Hình Hai Cổng IAM/RBAC

Phân biệt rạch ròi ai được kết nối và kết nối rồi làm được gì.

Các phương thức authentication: Google identity (OAuth/OIDC), IAM service account, OIDC third-party, X.509 client certificate, legacy basic auth (vì sao phải tắt)
Luồng kubectl → gke-gcloud-auth-plugin → OAuth token → API server → webhook token authentication
Mô hình hai cổng: IAM authorize việc gọi GKE API và kết nối cluster (cổng 1), RBAC authorize hành động trong cluster (cổng 2)
Vì sao cấp IAM role rộng (container.admin) thực chất bypass RBAC
ServiceAccount token: legacy token vs bound token (TokenRequest API, projected volume), thời hạn và audience

3. RBAC Deep Dive — Phân Quyền Trong Cluster

Cơ chế authorization bậc hai và cách thiết kế least-privilege.

Role vs ClusterRole, RoleBinding vs ClusterRoleBinding — ngữ nghĩa namespace-scoped vs cluster-scoped
Aggregated ClusterRoles: cơ chế label selector gộp quyền, các default role (admin, edit, view, cluster-admin)
GKE predefined IAM roles và ánh xạ sang RBAC: container.developer, container.clusterAdmin, container.admin, container.viewer
Anti-pattern chí mạng: cluster-admin cho ServiceAccount, wildcard * trong rules, binding cho group system:authenticated
Thiết kế RBAC theo namespace-per-team, audit quyền dư thừa, công cụ kubectl auth can-i

4. Workload Identity Federation — Cắt Đứt Con Đường Tới GCP API

Cách workload xác thực với Google API mà không cần key tĩnh.

Vấn đề gốc: long-lived service account key là credential nguy hiểm nhất trong GCP
Workload Identity Federation for GKE: pool PROJECT_ID.svc.id.goog, ánh xạ KSA → IAM principal
Token exchange ba bước qua GKE metadata server: KSA JWT → STS → federated access token
Định danh principal trực tiếp (principal://...) vs annotation iam.gke.io/gcp-service-account legacy
Workload Identity Federation cho external IdP (AWS, Azure, OIDC) → Google credential
Mối liên hệ với metadata concealment; deep-dive token path để ở Chương 13

5. Node Security — Cô Lập Tầng Hạ Tầng

Bảo vệ ranh giới node khỏi host và khỏi node khác.

Shielded GKE Nodes: Secure Boot, vTPM, Integrity Monitoring — chống rootkit và boot-level tampering
GKE Sandbox (gVisor): userspace kernel intercept syscall, runtimeClassName: gvisor, use case untrusted/multi-tenant, trade-off hiệu năng và giới hạn (không privileged, không hostPath)
Confidential GKE Nodes: AMD SEV mã hóa bộ nhớ data-in-use, chống hypervisor/host, machine series N2D
Container-Optimized OS (COS): read-only root filesystem, seccomp mặc định, minimal attack surface, automatic updates
Node service account: vì sao default Compute Engine SA nguy hiểm, nguyên tắc minimal permission, metadata concealment

6. Pod & Workload Security — securityContext và Pod Security Standards

Cô lập Pod khỏi node và Pod khỏi Pod ở tầng runtime.

Pod Security Standards: ba cấp Privileged → Baseline → Restricted, từng cấp cấm gì
Pod Security Admission (PSA): enforce/audit/warn theo namespace label (cross-ref Chương 10)
securityContext từng trường: runAsNonRoot, runAsUser, readOnlyRootFilesystem, allowPrivilegeEscalation, capabilities.drop: ALL, privileged
seccomp (RuntimeDefault) và AppArmor profiles: giảm syscall surface
Anti-pattern: chạy root, privileged container, mount hostPath nhạy cảm, automountServiceAccountToken không cần thiết

7. Network Policy Security — Default-Deny và Microsegmentation

Cô lập lưu lượng đông-tây trong cluster.

Vì sao mặc định Kubernetes là "flat network, allow-all" và tại sao đó là rủi ro lateral movement
Pattern default-deny: deny mọi ingress/egress rồi mở theo whitelist
Dataplane V2 (Cilium/eBPF): kiến trúc thay thế kube-proxy/iptables, hiệu năng và observability
FQDN-based egress policy (FQDNNetworkPolicy CRD trên Dataplane V2): kiểm soát egress theo DNS name
Network Policy logging, namespace isolation, hệ quả với DNS và control plane traffic

8. Admission Control Security — Enforcement Bằng Policy

Dùng admission control như một control plane bảo mật (cross-ref Chương 10 cho cơ chế).

Admission như cổng enforcement: chặn image từ registry không tin cậy, bắt buộc securityContext, cấm latest tag
ValidatingAdmissionWebhook: failure mode failurePolicy, timeout, rủi ro làm chết cluster nếu webhook down
MutatingAdmissionWebhook: sidecar injection (Istio), mutation tự động — và rủi ro bảo mật của mutation
Mutating Admission Policy / CEL (in-tree, không cần webhook): trade-off so với webhook
OPA/Gatekeeper vs Kyverno so sánh cho security policy; Policy Controller và constraint framework managed

9. Binary Authorization — Chỉ Deploy Image Đáng Tin

Đảm bảo chỉ image đã được verify mới chạy được trong cluster.

Mô hình attestation: image digest → attestor → attestation (ký số) → policy; vai trò Artifact Analysis/Container Analysis note
Execution path: deploy request → GKE admission controller → Binary Authorization API → kiểm tra policy → allow/deny + audit log
Policy modes: allowlist registry, require attestation, dryRun để test không chặn
Break-glass: annotation khẩn cấp để bypass policy, và vì sao mọi break-glass đều được audit
Continuous Validation (CV): quét Pod đang chạy định kỳ, phát hiện image vi phạm policy sau khi deploy
Cloud Build integration: tự động sinh attestation và provenance trong CI/CD (SLSA)

10. Audit Logging, Security Posture & Hardening Checklist

Quan sát, phát hiện và checklist hardening tổng hợp.

Cloud Audit Logs bốn loại: Admin Activity (luôn bật, miễn phí), Data Access (phải bật, tốn phí), System Event, Policy Denied — và hệ quả compliance
Kubernetes audit log trên GKE: ánh xạ vào Cloud Logging, query forensics điển hình
GKE Security Posture: config scanning (security bulletins), workload vulnerability scanning, tích hợp Security Command Center và Artifact Analysis
Checklist hardening đầy đủ: control plane (private endpoint, authorized networks, tắt legacy auth), node (Shielded, COS, node SA, metadata concealment), Pod (PSA Restricted, securityContext), network (default-deny), supply chain (Binary Authorization)

Bản đồ tinh thần: bảy lớp phòng thủ của GKE

Trước khi đi vào từng file, hãy ghim mô hình bảy lớp này. Nó là khung tham chiếu cho mọi quyết định thiết kế và debug bảo mật trong chương. Mỗi lớp bảo vệ một failure domain, và việc phá vỡ một lớp không được tự động phá vỡ lớp bao quanh.

Lớp	Failure domain	Cơ chế bảo vệ chính	File
Organization / Project	Toàn bộ tổ chức	IAM, Org Policy, VPC Service Controls, resource hierarchy	1, 2
Cluster control plane	Toàn cluster	Private endpoint, authorized networks, tắt legacy auth, RBAC	1, 2, 3
Identity & access	Quyền trong cluster	IAM ↔ RBAC two-gate, least privilege, Workload Identity	2, 3, 4
Node	Một máy + mọi Pod trên nó	Shielded, Confidential, gVisor, COS, node SA tối thiểu	5
Pod / workload	Một Pod	Pod Security Standards, securityContext, seccomp, AppArmor	6
Network	Lateral movement đông-tây	Network Policy default-deny, Dataplane V2, FQDN egress	7
Supply chain	Image chạy trong cluster	Binary Authorization, attestation, Artifact Analysis, admission policy	8, 9

Hai quan sát quan trọng từ mô hình này:

Mỗi lớp có một "owner" và một cơ chế enforcement khác nhau. IAM được enforce bởi Google ở tầng GCP API; RBAC bởi API server; securityContext bởi kubelet + container runtime; Network Policy bởi Dataplane V2 ở tầng eBPF; Binary Authorization bởi admission controller. Khi debug một sự cố bảo mật, câu hỏi đầu tiên là "lớp nào đã bị vượt qua, và cơ chế enforcement của nó là gì" — vì điểm điều tra và điểm vá lỗi nằm ở các tầng khác nhau.
Lớp càng gần workload, càng dễ cấu hình sai và càng dễ bị bỏ qua. IAM và control plane hardening thường được làm một lần lúc tạo cluster. Nhưng securityContext, Network Policy, image policy phải đúng trên mọi workload, mọi lần deploy — và đó là nơi misconfiguration tích lũy. Đây là lý do enforcement tự động (Pod Security Admission, Policy Controller, Binary Authorization) quan trọng hơn nhiều so với kỷ luật thủ công: con người sẽ quên, policy thì không.

Khung quyết định bảo mật (tóm tắt)

Đây là ma trận quyết định cốt lõi của chương. Mỗi dòng là một câu hỏi thiết kế thật, file tương ứng đào sâu.

Tình huống / Nhu cầu	Lựa chọn đúng	Vì sao	File
Cấp quyền cho developer xem/deploy trong một namespace	`container.developer` (IAM) + RBAC namespace-scoped	Least privilege, không chạm cluster khác	2, 3
Workload cần gọi Cloud Storage / Pub/Sub	Workload Identity Federation, không dùng SA key	Không có credential tĩnh để rò rỉ	4
Chạy untrusted code / third-party / multi-tenant	GKE Sandbox (gVisor) trên node pool riêng	Cô lập syscall, chống container escape	5
Compliance yêu cầu mã hóa data-in-use	Confidential GKE Nodes (AMD SEV)	Bộ nhớ mã hóa, chống hypervisor	5
Ngăn Pod chạy root / privileged	Pod Security Admission cấp `restricted` + securityContext	Enforce tự động, không dựa kỷ luật	6
Ngăn Pod bị chiếm quyền gọi ra Internet/Pod khác	Network Policy default-deny + FQDN egress	Cắt lateral movement và exfiltration	7
Chỉ cho deploy image đã qua CI/CD scan	Binary Authorization require-attestation	Chặn image không rõ nguồn gốc	9
Bắt buộc image từ registry nội bộ, cấm `latest`	Admission policy (Gatekeeper/Kyverno/CEL)	Enforce supply chain ở deploy time	8
Điều tra forensics khi nghi bị tấn công	Data Access audit log + Kubernetes audit log	Dấu vết ai làm gì, khi nào	10
Phát hiện misconfiguration trên toàn cluster	GKE Security Posture + SCC	Quét liên tục, surfacing tự động	10

Năm sai lầm xuyên suốt thường gặp ở cấp chương

Cấp IAM role rộng để "cho nhanh". Gán roles/container.admin cho cả team developer vì RBAC "phức tạp". Hệ quả: mọi developer thực chất là cluster-admin, bypass toàn bộ RBAC, và một credential developer bị lộ = toàn cluster bị chiếm. Đúng: IAM tối thiểu (container.developer hoặc clusterViewer) + RBAC namespace-scoped chi tiết (file 2, 3).
Coi container là security boundary. Chạy untrusted hoặc multi-tenant workload trên node thường, không sandbox, root được phép. Một container escape qua CVE kernel = node compromise = mọi tenant trên node đó bị lộ. Đúng: gVisor cho untrusted, node pool riêng cho mỗi tenant nhạy cảm, Pod Security restricted (file 5, 6).
Dùng service account key tĩnh cho workload. Tạo SA, export JSON key, mount vào Pod làm Secret. Key này không hết hạn, nằm trong Git/image/etcd, và là vector lộ credential số một. Đúng: Workload Identity Federation, zero long-lived key (file 4).
Để network phẳng allow-all. Không có Network Policy nào, mọi Pod nói chuyện được với mọi Pod và ra Internet tự do. Một Pod bị chiếm = bàn đạp quét và pivot toàn cluster. Đúng: default-deny baseline + whitelist tối thiểu + FQDN egress (file 7).
Tin tưởng image mà không verify. Deploy bất kỳ image nào pull được, kể cả latest từ Docker Hub. Không biết image chứa gì, không có chuỗi cung ứng tin cậy. Đúng: Binary Authorization require-attestation + vulnerability scanning + admission policy chặn registry lạ (file 8, 9).

Cross-reference với Google Cloud Architecture Framework

Security pillar: chương này là hiện thân trực tiếp của trụ cột Security trong Well-Architected Framework — defense-in-depth, least privilege, zero-trust identity, supply chain security (Security pillar).
Reliability: hardening sai cách có thể gây outage — webhook failurePolicy: Fail làm chết admission, Network Policy quá chặt làm hỏng DNS. Bảo mật và độ tin cậy là trade-off phải cân bằng có ý thức (Reliability pillar).
Operational excellence: audit logging, Security Posture, và enforcement tự động là nền tảng để vận hành bảo mật ở quy mô — không thể bảo mật thủ công hàng nghìn workload (Operational excellence pillar).

References chung của chapter

Bảng thuật ngữ then chốt của chương

Thuật ngữ	Ý nghĩa ngắn gọn
Shared responsibility	Phân chia trách nhiệm bảo mật giữa Google và customer (file 1)
Defense-in-depth	Nhiều lớp phòng thủ độc lập, không phụ thuộc một lớp duy nhất (file 1)
Two-gate model	IAM authorize kết nối, RBAC authorize hành động (file 2)
RBAC	Role-Based Access Control trong cluster (Role/ClusterRole/Binding) (file 3)
Workload Identity	Ánh xạ KSA → IAM principal, không cần key tĩnh (file 4)
GKE metadata server	Thành phần thực hiện token exchange cho Workload Identity (file 4)
Shielded nodes	Secure Boot + vTPM + Integrity Monitoring (file 5)
gVisor	Userspace kernel sandbox, `runtimeClassName: gvisor` (file 5)
Confidential nodes	AMD SEV mã hóa bộ nhớ data-in-use (file 5)
COS	Container-Optimized OS, read-only rootfs, seccomp mặc định (file 5)
Pod Security Standards	Ba cấp Privileged/Baseline/Restricted (file 6)
securityContext	Cấu hình bảo mật cấp Pod/container (file 6)
Dataplane V2	Datapath eBPF/Cilium thay kube-proxy, nền cho Network Policy nâng cao (file 7)
Default-deny	Pattern chặn mọi traffic rồi whitelist (file 7)
Attestation	Chứng nhận ký số rằng image đã qua một bước CI/CD (file 9)
Attestor	Authority verify attestation trong Binary Authorization (file 9)
Break-glass	Annotation bypass Binary Authorization khẩn cấp, được audit (file 9)
Continuous Validation	Quét Pod đang chạy để phát hiện vi phạm policy (file 9)
Audit log (4 loại)	Admin Activity, Data Access, System Event, Policy Denied (file 10)
Security Posture	Dashboard quét config + vulnerability của GKE (file 10)

Kết luận của chapter

Bảo mật GKE là môn học về ranh giới và niềm tin. Mỗi cơ chế trong chương này tồn tại để trả lời một câu hỏi: "ai/cái gì được tin tưởng vượt qua ranh giới này, và bằng chứng gì cho phép điều đó?" IAM trả lời cho ranh giới project; RBAC cho ranh giới cluster; securityContext cho ranh giới node; gVisor/Confidential cho ranh giới kernel/host; Network Policy cho ranh giới mạng; Binary Authorization cho ranh giới supply chain. Hardening không phải là bật càng nhiều tính năng càng tốt — nó là việc đảm bảo mọi ranh giới đều có một cơ chế enforcement rõ ràng, và việc vượt qua một ranh giới đòi hỏi bằng chứng tường minh, để lại dấu vết audit.

Cách dùng chương hiệu quả nhất là biến mỗi file thành một chuẩn enforcement: chuẩn về ai được kết nối và làm gì (file 2, 3), chuẩn về workload xác thực không key (file 4), chuẩn về cô lập node và Pod (file 5, 6), chuẩn về microsegmentation mạng (file 7), chuẩn về supply chain (file 8, 9), và chuẩn về quan sát và checklist tổng hợp (file 10). Khi đó bảo mật chuyển từ "một danh sách tính năng đã bật" thành một hệ thống các ranh giới có thể suy luận, kiểm chứng, và audit được một cách kỷ luật — đúng tinh thần zero-trust mà mọi production cluster ở quy mô lớn buộc phải theo.

Chương 12: GKE Security — Hardening, RBAC, Pod Security ​

Vì sao chương này quyết định ranh giới giữa "an toàn" và "bị chiếm quyền" ​

Điều kiện tiên quyết ​

Mức độ sâu ​

Cấu trúc chapter ​

Bản đồ tinh thần: bảy lớp phòng thủ của GKE ​

Khung quyết định bảo mật (tóm tắt) ​

Năm sai lầm xuyên suốt thường gặp ở cấp chương ​

Cross-reference với Google Cloud Architecture Framework ​

References chung của chapter ​

Bảng thuật ngữ then chốt của chương ​

Kết luận của chapter ​