Confidential GKE Nodes — Kiến Trúc & Triển Khai
Từ Confidential VM Tới Confidential GKE Nodes: Không Chỉ Là "Bật Cờ Cho Node"
Ở ba file trước, chúng ta đã đi sâu vào cơ chế phần cứng của AMD SEV/SEV-ES/SEV-SNP và Intel TDX ở tầng Compute Engine VM đơn lẻ. Confidential GKE Nodes không phải một công nghệ riêng — nó là lớp tích hợp GKE trên nền Compute Engine Confidential VM, nơi mỗi node trong cluster (hoặc node pool) chính là một Confidential VM instance, và kubelet/container runtime chạy bên trong VM đó như bình thường. Điều này có nghĩa là mọi giới hạn đã trình bày ở các file trước — machine type nào hỗ trợ công nghệ nào, ràng buộc Local SSD, live migration — đều áp dụng nguyên vẹn cho node GKE, cộng thêm một tầng ràng buộc mới riêng của GKE: cách cấu hình được phân cấp theo ba mức độ (cluster, node pool, workload), và cách các Pod trên node đó tương tác với phần cứng bảo mật bên dưới.
Điểm mấu chốt cần hiểu ngay từ đầu: container không tạo ra ranh giới cách ly bổ sung nào cho Confidential Computing. Một Pod chạy trên Confidential GKE Node được bảo vệ bởi vì toàn bộ node (namespace kernel, container runtime, mọi Pod trên node đó) đang chạy bên trong một Confidential VM duy nhất — bộ nhớ được mã hóa ở tầng VM, không phải ở tầng container riêng lẻ. Hệ quả trực tiếp: mọi Pod trên cùng một node Confidential đều nằm trong cùng một trust boundary — nếu bạn cần cách ly bảo mật giữa các tenant khác nhau ở mức độ Confidential Computing (ví dụ tenant A không được share cùng node vật lý/VM với tenant B), bạn phải đảm bảo chúng chạy trên các node pool khác nhau, không thể chỉ dựa vào namespace Kubernetes hay NetworkPolicy.
Theo tài liệu chính thức, Confidential GKE Nodes hiện hỗ trợ đầy đủ ba công nghệ đã trình bày: "AMD Secure Encrypted Virtualization (SEV)", "AMD Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP)", và "Intel Trust Domain Extensions (TDX)" (Confidential GKE Nodes documentation).
Ba Cấp Độ Cấu Hình: Cluster, Node Pool, Workload
Đây là quyết định thiết kế trung tâm của Confidential GKE Nodes, và hiểu rõ sự khác biệt giữa ba cấp độ này là điều kiện bắt buộc để không rơi vào tình huống cluster bị khóa cứng vào một cấu hình không mong muốn.
Cấp độ Cluster: Toàn Cluster Là Confidential, Không Thể Đảo Ngược
Bạn có thể bật Confidential GKE Nodes ngay tại thời điểm tạo cluster. Khi làm vậy, mọi node pool tạo ra sau này trong cluster đó bắt buộc phải là confidential node — bạn không còn khả năng tạo node pool thường (non-confidential) trong cluster này nữa. Đây là hệ quả trực tiếp từ nguyên tắc đã trình bày ở file 01: khóa mã hóa gắn với vòng đời khởi tạo VM, và quyết định "cluster này là confidential" ảnh hưởng tới cách control plane quản lý identity và policy cho toàn bộ node fleet — quyết định này không thể đảo ngược sau khi cluster đã được tạo. Máy chủ mặc định thay đổi tùy theo công nghệ được chọn ở cấp cluster: N2D cho SEV/SEV-SNP, C3 cho TDX.
Cấp độ Node Pool: Linh Hoạt Hơn, Nhưng Có Điều Kiện Tiên Quyết
Với GKE Standard, bạn có thể cấu hình Confidential Nodes cho từng node pool cụ thể, thay vì toàn bộ cluster — cho phép trộn lẫn node pool thường và node pool confidential trong cùng một cluster. Tuy nhiên, điều này chỉ khả dụng khi Confidential GKE Nodes đang bị tắt ở cấp độ cluster. Nói cách khác, hai cấp độ này loại trừ lẫn nhau về mặt logic điều khiển: nếu bạn đã bật ở cấp cluster, mọi node pool tự động là confidential và bạn không cần (cũng không thể) cấu hình riêng lẻ; nếu cluster không bật, bạn có toàn quyền chọn node pool nào là confidential, node pool nào không.
Cấp độ Workload: Linh Hoạt Nhất, Qua Custom ComputeClass
Cấp độ mới nhất và linh hoạt nhất là cấu hình ở tầng workload, thông qua Custom ComputeClass — một cơ chế đã trình bày ở Chương 8 cho phép định nghĩa một "hồ sơ" thuộc tính node (bao gồm cả yêu cầu confidential computing) mà một Deployment cụ thể có thể yêu cầu qua nodeSelector/spec.nodeSelector trỏ tới ComputeClass đó, độc lập với cấu hình mặc định của cluster. Đây là cách tiếp cận duy nhất hỗ trợ đầy đủ cả ba công nghệ (SEV, SEV-SNP, TDX) bất kể cluster được cấu hình gì ở cấp cao hơn — và cũng là con đường bắt buộc để dùng Confidential Computing trên GKE Autopilot, nơi bạn không có quyền quản lý node pool trực tiếp như Standard.
Ràng Buộc Riêng Của Node Auto-Provisioning
Một chi tiết vận hành dễ bị bỏ sót: Node Auto-Provisioning (NAP), cơ chế tự động tạo node pool mới khi cần (đã trình bày ở Chương 9), chỉ hỗ trợ AMD SEV và AMD SEV-SNP ở cấp độ node pool — không hỗ trợ tự động tạo node pool Intel TDX. Nếu bạn cần TDX và muốn tận dụng NAP, giải pháp duy nhất là cấu hình ở tầng workload qua ComputeClass thay vì trông chờ NAP tự tạo node pool TDX.
Yêu Cầu Phiên Bản GKE
Yêu cầu phiên bản khác nhau đáng kể giữa các công nghệ và giữa Standard/Autopilot:
- AMD SEV: cluster GKE Autopilot cần phiên bản 1.30.2 trở lên. Với cluster Standard, AMD SEV khả dụng trên bất kỳ phiên bản GKE nào (không có yêu cầu phiên bản tối thiểu đặc biệt).
- AMD SEV-SNP và Intel TDX trên Autopilot: yêu cầu phiên bản mới hơn đáng kể, 1.35.2-gke.1485000 trở lên — phản ánh việc đây là các công nghệ được tích hợp muộn hơn vào managed control plane của Autopilot so với SEV gốc.
- Với cluster Standard, yêu cầu phiên bản có thể thay đổi tùy loại hệ điều hành node (Container-Optimized OS so với Ubuntu) — cần kiểm tra release note tương ứng với phiên bản GKE cụ thể trước khi lập kế hoạch nâng cấp.
Sự chênh lệch phiên bản yêu cầu này có một hệ quả vận hành thực tế: nếu bạn đang chạy một cluster Autopilot ở phiên bản cũ hơn 1.35.2-gke.1485000 và cần dùng SEV-SNP hoặc TDX, bạn buộc phải lên kế hoạch nâng cấp cluster (xem Chương 15 về cơ chế upgrade) trước khi có thể triển khai — đây không phải là một cấu hình có thể bật ngay lập tức trên mọi cluster đang chạy.
Ma Trận Machine Type Theo Công Nghệ Trong Bối Cảnh GKE
Kế thừa trực tiếp từ ma trận Compute Engine đã trình bày ở các file trước, nhưng với GKE cần lưu ý thêm về machine family mặc định theo từng công nghệ khi cấu hình ở cấp cluster:
| Công nghệ | Machine series mặc định khi cấu hình cấp cluster | Machine series khả dụng khác |
|---|---|---|
| AMD SEV | N2D | C2D, C3D, C4D |
| AMD SEV-SNP | N2D | (chỉ N2D) |
| Intel TDX | C3 | c3-standard-*-lssd (biến thể có Local SSD) |
Việc chọn sai machine series ngay từ khi thiết kế node pool có thể dẫn tới việc phải rebuild lại toàn bộ node pool sau này — vì như đã trình bày, không thể "chuyển đổi" một node đang chạy sang cấu hình confidential khác, chỉ có thể tạo node pool mới và drain/migrate workload sang.
Giới Hạn Kỹ Thuật Tổng Hợp Áp Dụng Cho Confidential GKE Nodes
Tài liệu chính thức nêu rõ nguyên tắc bao trùm: "All of the limitations of Compute Engine Confidential VM instances also apply to Confidential GKE Nodes" (Confidential GKE Nodes concepts) — nghĩa là mọi ràng buộc đã trình bày ở file 02 và file 03 (giới hạn vNIC queue, băng thông giảm, không hỗ trợ Hyperdisk Balanced/Throughput trên C3D, không reservation cho SEV-SNP, không kdump cho TDX...) đều kế thừa nguyên vẹn. Bên cạnh đó, GKE bổ sung thêm các giới hạn đặc thù riêng:
- Không tương thích với sole-tenant node: bạn không thể yêu cầu node pool Confidential chạy trên phần cứng vật lý độc quyền mà bạn kiểm soát placement — một ràng buộc quan trọng nếu tổ chức của bạn có yêu cầu compliance đòi hỏi tách biệt vật lý (physical isolation) ngoài tách biệt logic.
- Chỉ hỗ trợ ephemeral storage trên Local SSD, không hỗ trợ Local SSD nói chung: bạn có thể dùng Local SSD làm ephemeral storage tạm thời (ví dụ cho scratch space của workload), nhưng không thể dùng nó như một volume type thông thường được mount trực tiếp và trông cậy vào tính bền vững qua node restart — điều này hạn chế đáng kể các use case yêu cầu Local SSD hiệu năng cao cho database self-managed (đã trình bày ở Chương 11).
- Chỉ hỗ trợ Container-Optimized OS và Ubuntu; không hỗ trợ Windows node: nếu bạn có nhu cầu chạy Windows Server container (xem chương liên quan trong phần khác của handbook), chúng không thể chạy trên Confidential GKE Nodes ở thời điểm hiện tại.
- Không thể cập nhật cluster/node pool hiện có để thay đổi chế độ Confidential cho Hyperdisk Balanced: một khi node pool đã được tạo với một cấu hình Hyperdisk Balanced cụ thể liên quan tới confidential mode, việc thay đổi sau này đòi hỏi tạo lại node pool, không phải một thao tác cập nhật tại chỗ.
Cơ Chế vTPM Cho Pod: Mở Rộng Attestation Từ Node Xuống Workload
Một câu hỏi vận hành quan trọng: nếu bạn muốn một Pod cụ thể tự thực hiện attestation (ví dụ để verify chính nó trước khi truy cập một tài nguyên nhạy cảm, thay vì chỉ tin tưởng "node là confidential nên Pod tự động an toàn"), làm sao Pod truy cập được vTPM của node? Mặc định, vTPM là một thiết bị cấp node (do firmware ảo của VM cung cấp), không tự động expose vào bên trong container namespace. GKE cung cấp cơ chế riêng để làm điều này: theo tài liệu, "vTPMs only work with AMD SEV confidential computing. Intel TDX and AMD SEV-SNP aren't supported" cho tính năng này (Run a vTPM in Confidential GKE Nodes workloads).
Đây là một giới hạn quan trọng cần nhấn mạnh: khả năng cho phép Pod truy cập trực tiếp vTPM hiện chỉ hoạt động với AMD SEV, yêu cầu machine type N2D hoặc C2D, hệ điều hành Container-Optimized OS với containerd. Quy trình triển khai gồm ba bước:
- Tạo cluster confidential dùng AMD SEV qua gcloud hoặc Console, đúng như cấu hình cấp cluster đã trình bày ở trên.
- Triển khai một DaemonSet chuyên dụng chạy trên mọi node cần expose vTPM — DaemonSet này chịu trách nhiệm thiết lập device plugin cho phép container truy cập vTPM device an toàn.
- Cấu hình resource limit trên Pod với trường đặc biệt
google.com/cc: 1— đây là một extended resource (khái niệm đã trình bày ở Chương 8 khi nói về GPU) mà scheduler dùng để chỉ định Pod này cần được cấp quyền truy cập thiết bị vTPM:
resources:
limits:
google.com/cc: 1Ý nghĩa thực tế của giới hạn "chỉ AMD SEV" này: nếu kiến trúc của bạn cần Pod tự thực hiện attestation cấp workload (ví dụ pattern secure key release chi tiết ở file 05) và bạn đang dùng Intel TDX hoặc SEV-SNP, bạn không thể dựa vào cơ chế vTPM-in-Pod này — thay vào đó phải dùng các công cụ attestation ở tầng khác (ví dụ Confidential Space, vốn hoạt động độc lập với việc Pod có truy cập trực tiếp vTPM hay không, vì nó attest ở tầng VM/launcher chứ không đưa TPM device vào container).
Xác Minh Node Đã Chạy Confidential Computing
Về mặt vận hành, khi debug hoặc audit một cluster, cách xác minh nhanh nhất một node có đang chạy dưới chế độ confidential hay không là kiểm tra label hệ thống trên đối tượng Node: chạy kubectl describe NODE_NAME và tìm label cloud.google.com/gke-confidential-nodes-instance-type. Giá trị của label này phản ánh công nghệ cụ thể đang được sử dụng (ví dụ giá trị tương ứng SEV, SEV-SNP, hoặc TDX). Đây là cách kiểm tra thực tế, đáng tin cậy hơn nhiều so với việc chỉ dựa vào tên machine type — vì như đã trình bày, cùng một machine series (ví dụ N2D) có thể chạy ở chế độ confidential hoặc không confidential tùy cấu hình lúc tạo node pool.
Extension Sang Confidential GPU Trên GKE
Ngoài phạm vi CPU, GKE cũng hỗ trợ mở rộng bảo vệ Confidential Computing sang GPU đi kèm — cho phép các workload AI/ML training/inference nhạy cảm chạy trên node có cả CPU (TDX) và GPU (NVIDIA Confidential Computing, ví dụ H100) đều ở chế độ confidential. Đây là một cấu hình chuyên biệt được tài liệu hóa riêng ("Encrypt GPU workload data in-use with Confidential GKE Nodes"), nằm ngoài phạm vi chi tiết của chương này (xem Chương 49 về hạ tầng AI/ML trên GKE để biết thêm bối cảnh triển khai GPU tổng quát), nhưng cần lưu ý nguyên tắc quan trọng đã nêu ở file 03: bảo vệ CPU và GPU phải được bật đồng thời — chỉ bật một trong hai sẽ để lộ khoảng trống dữ liệu-đang-sử-dụng ở phía còn lại.
Ví Dụ Cấu Hình Thực Tế Ở Từng Cấp Độ
Để việc phân biệt ba cấp độ cấu hình không chỉ dừng ở lý thuyết, đáng để hình dung cách chúng thể hiện qua công cụ thực tế. Ở cấp node pool trên cluster Standard, việc tạo một node pool riêng chạy AMD SEV trên machine type C3D thường được thực hiện qua gcloud với cờ chỉ định rõ công nghệ và machine type mong muốn — tương tự cách các node pool khác được tạo và quản lý như đã trình bày ở Chương 6, chỉ khác ở việc bổ sung cờ bật Confidential Computing và chỉ định đúng công nghệ (SEV, SEV-SNP, hay TDX) khớp với machine type đã chọn — sai lệch giữa hai giá trị này sẽ bị từ chối ngay ở bước tạo node pool.
Ở cấp workload qua Custom ComputeClass, cấu hình được biểu diễn dưới dạng một custom resource khai báo yêu cầu về node — bao gồm công nghệ confidential computing cụ thể — và Deployment/Pod tham chiếu tới ComputeClass đó qua nodeSelector giống hệt cách các thuộc tính khác của ComputeClass (đã trình bày ở Chương 8) được tiêu thụ. Cách tiếp cận này tách biệt hoàn toàn quyết định "workload nào cần confidential computing" ra khỏi quyết định "cluster/node pool được cấu hình sẵn thế nào", cho phép đội phát triển ứng dụng tự khai báo yêu cầu bảo mật ngay trong manifest của mình mà không cần phối hợp trước với đội quản lý hạ tầng để tạo riêng một node pool — miễn là cluster đã bật Autopilot hoặc đã cấu hình ComputeClass tương ứng sẵn sàng.
Tương Tác Với Cluster Disruption Budget Và Upgrade
Một khía cạnh vận hành dễ bị bỏ sót: node pool Confidential vẫn tuân theo toàn bộ cơ chế upgrade, maintenance window, và cluster disruption budget đã trình bày ở Chương 15, nhưng với một lớp phức tạp bổ sung — như đã đề cập ở file 03, các instance TDX có thời gian shutdown lâu hơn VM tiêu chuẩn. Khi lập kế hoạch maintenance window hoặc surge upgrade cho node pool TDX, cần tính thêm buffer thời gian cho bước teardown TD an toàn (xóa khóa mã hóa, giải phóng tài nguyên SEAM) — nếu maintenance window được cấu hình quá chật (theo yêu cầu 48h/32 ngày đã trình bày ở Chương 15 phần maintenance windows), quá trình upgrade node pool TDX có nguy cơ chạy vượt ra ngoài cửa sổ dự kiến so với node pool non-confidential tương đương.
Mental Model Tổng Kết: Ba Cấp Độ Là Trade-off Giữa Kiểm Soát Và Sự Đơn Giản
Trước khi sang phần attestation, hãy chốt lại mental model về ba cấp độ cấu hình:
- Cấp cluster cho sự đơn giản và đảm bảo mạnh nhất ("mọi thứ trong cluster này đều confidential, không có ngoại lệ nào bị bỏ sót") — đánh đổi bằng tính không thể đảo ngược và không thể trộn lẫn với workload không cần confidential trong cùng cluster.
- Cấp node pool cho sự linh hoạt trung gian trên Standard — bạn quyết định workload nào cần chạy trên node đắt hơn (về overhead hiệu năng) và có ràng buộc hạ tầng chặt hơn (không sole-tenant, giới hạn storage), workload nào không cần.
- Cấp workload qua ComputeClass cho sự linh hoạt tối đa và là con đường duy nhất trên Autopilot, đồng thời là cách duy nhất hỗ trợ đầy đủ cả ba công nghệ độc lập với cấu hình cluster.
Quyết định chọn cấp độ nào không chỉ là vấn đề sở thích vận hành — nó ảnh hưởng trực tiếp tới khả năng bạn có thể thay đổi kiến trúc sau này mà không phải xây lại cluster từ đầu. Với hiểu biết về "node nào đang chạy confidential, công nghệ nào" đã có, phần tiếp theo sẽ trả lời câu hỏi quan trọng nhất về mặt bảo mật thực chất: làm sao chứng minh với một hệ thống bên ngoài rằng node/Pod đó thực sự đang chạy đúng như những gì bạn tuyên bố.