Kỹ sư QLTT Ghi chú ôn thi
← Về danh sách
Bảo mật & Quyền riêng tư
#ConfidentialContainers#CoCo#ConfidentialComputing#TEE#Kubernetes#KataContainers#RemoteAttestation#KeyBrokerService#PeerPods
Cập nhật lần cuối · 2026-09-27

Bảo vệ workload bảo mật trên Kubernetes dựa trên Confidential Containers (CoCo)

1. Tổng quan

A. Định nghĩa

Confidential Containers (CoCo) là phương thức điện toán bảo mật (confidential computing) cloud-native chạy Pod Kubernetes bên trong TEE (Trusted Execution Environment - môi trường thực thi tin cậy) dựa trên phần cứng, nhằm bảo vệ dữ liệu đang xử lý và mã workload khỏi hạ tầng host, hypervisor và các tenant khác.

Container thông thường cô lập tiến trình và hệ thống tệp, nhưng kernel host và hypervisor mà các container dùng chung có thể không nằm ngoài ranh giới tin cậy của workload. Nếu nhà vận hành đám mây hay quản trị viên host có quyền mạnh, thông tin đang xử lý có thể bị lộ qua memory dump, truy cập kho image hoặc lạm dụng giao diện gỡ lỗi. Vấn đề cốt lõi là chỉ mã hóa đĩa và mã hóa đường truyền thì không thể bảo vệ khoảnh khắc ứng dụng xử lý bản rõ trong bộ nhớ.

CoCo kết hợp cách ly máy ảo nhẹ theo đơn vị Pod của Kata Containers với các chức năng mã hóa·toàn vẹn bộ nhớ phần cứng như AMD SEV-SNP, Intel TDX. Hơn nữa, nó chỉ chuyển khóa giải mã image và bí mật sau khi bên kiểm chứng từ xa xác nhận giá trị đo lường của môi trường thực thi, qua đó mở rộng sự kiện "đã bật VM được mã hóa" thành phán đoán tin cậy "phần mềm được phê duyệt đang chạy trên TEE được phê duyệt". Do đó, bản chất của CoCo không phải là một tùy chọn bảo mật container đơn thuần mà là chuỗi cung ứng tin cậy của workload, nối liền cách ly, đo lường, kiểm chứng và chuyển giao bí mật.

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

Thứ nhất, trong điện toán đám mây, nhà cung cấp hạ tầng và chủ sở hữu dữ liệu không phải là một. Khi tổ chức tài chính thực hiện phân tích trên đám mây bên ngoài, hoặc doanh nghiệp sản xuất cùng chạy mô hình của nhiều đối tác, cần xử lý nghiệp vụ mà không phải tin tưởng hoàn toàn nhà vận hành hạ tầng. CoCo cung cấp lựa chọn tách dữ liệu và mô hình nhạy cảm bên trong workload khỏi ranh giới tin cậy của hạ tầng, trong khi vẫn giữ sự tiện lợi vận hành của Kubernetes được quản lý.

Thứ hai, AI tạo sinh và cộng tác dữ liệu phải bảo vệ không chỉ dữ liệu đầu vào mà cả trọng số mô hình và prompt. Nếu image container nằm ở dạng bản rõ trong registry của host và cache của node thì chỉ mã hóa bộ nhớ là chưa đủ. CoCo kết hợp với kiểm chứng chữ ký image, image mã hóa và cấp phát khóa dựa trên chứng thực từ xa (remote attestation) để cùng kiểm soát vòng đời của image, môi trường thực thi và bí mật.

Thứ ba, điều quan trọng là không phải từ bỏ các công cụ Kubernetes hiện có. CoCo tận dụng runtimeClassName trong YAML của Pod, image OCI chuẩn và lập lịch của Kubernetes, nên có thể chọn hồ sơ thực thi được bảo vệ mà không phải viết lại toàn bộ ứng dụng. Tuy nhiên, không phải mọi Pod đều tự động trở nên an toàn; ranh giới tin cậy của control plane, registry, key broker, log và storage phải được thiết kế riêng.

C. Mục tiêu và phạm vi

Mục tiêu hàng đầu của CoCo là tính bí mật của dữ liệu đang sử dụng (data in use) và tính toàn vẹn của mã thực thi. Dữ liệu lưu trữ được bảo vệ bằng mã hóa đĩa và image mã hóa, dữ liệu truyền tải bằng TLS và xác thực giữa các dịch vụ, dữ liệu đang xử lý bằng mã hóa bộ nhớ và kiểm soát truy cập của TEE. Chứng thực từ xa là căn cứ phán đoán nối liền ba biện pháp bảo vệ này, bản thân nó không thay thế mã hóa dữ liệu.

Đối tượng bảo vệ của CoCo là Pod workload và các thành phần guest hạn chế hỗ trợ Pod. API server của Kubernetes, control plane, kernel host, hypervisor và các Pod khác về cơ bản được xem là các yếu tố không tin cậy nằm ngoài vùng bảo mật. Chỉ khi xác định rõ phạm vi bảo vệ như vậy mới tránh được các tuyên bố bảo mật phóng đại như "toàn bộ node được bảo vệ" hay "nhà vận hành Kubernetes không thể thấy bất kỳ thông tin nào".

2. Mô hình mối đe dọa và ranh giới tin cậy

A. Giả định tấn công

CoCo giả định rằng quản trị viên host đám mây hoặc hypervisor độc hại có thể cố quan sát·sửa đổi bộ nhớ guest và việc thực thi CPU. Nó cũng xem xét khả năng kẻ tấn công chiếm quyền container runtime của node, sao chép các lớp image, hoặc thử yêu cầu debug·exec qua API Kubernetes. Giả định này không phải là mô hình giải quyết lỗ hổng ứng dụng hay mã độc, mà lấy image và chính sách đã được phê duyệt làm tiền đề.

Các mối đe dọa tiêu biểu có thể chia thành bốn loại. Thứ nhất, lộ bộ nhớ, khi host đọc các trang bộ nhớ của VM để lấy bản rõ. Thứ hai, lộ chuỗi cung ứng, khi image·script khởi tạo·secret bị sao chép từ kho lưu trữ của host. Thứ ba, xâm phạm tính toàn vẹn, khi hypervisor thay đổi image khởi động guest hoặc cấu hình runtime để chạy mã chưa được phê duyệt. Thứ tư, thất bại ranh giới vận hành, khi nhà vận hành dùng quyền Kubernetes quá mức để vào bên trong Pod, hoặc làm lộ lại dữ liệu nhạy cảm qua log và volume tạm.

B. Ranh giới tin cậy lấy Pod làm trung tâm

flowchart LR
    U[Workload Pod] --> G[Guest helper and Kata agent]
    G --> T[TEE boundary]
    T --> H[Encrypted guest memory]
    H -. untrusted .-> HV[Hypervisor]
    HV -. untrusted .-> N[Host kernel and node]
    N -. untrusted .-> CP[Kubernetes control plane]
    CP -. untrusted .-> O[Other pods]

Điểm cốt lõi mà tài liệu thiết kế của CoCo giải thích là đặt Pod workload cùng các tiến trình·daemon hỗ trợ nó bên trong enclave, còn hypervisor, các Pod khác và control plane ở bên ngoài. Đây là sự dung hòa giữa cách tiếp cận node-centric đưa toàn bộ node vào TEE và cách tiếp cận container-centric chỉ tách riêng một container. Vì nhiều container trong một Pod có thể dùng chung network namespace và volume, nó không tạo thêm đường giao tiếp buộc phải đẩy service mesh hay sidecar ra ngoài enclave.

Cách tiếp cận node-centric dễ đưa cả kubelet và agent của node vào TCB (Trusted Computing Base - cơ sở tính toán tin cậy), khiến bề mặt tấn công của guest và phạm vi kiểm chứng lớn lên. Ngược lại, cách tiếp cận container-centric phải nối lại ranh giới mạng·IPC để phục vụ việc chia sẻ bình thường giữa các container, làm tăng độ phức tạp cấu hình và chi phí hiệu năng. Cách tiếp cận Pod-centric nằm giữa hai thái cực này, giữ TCB tương đối nhỏ và gói một đơn vị nghiệp vụ vào Pod để dễ vận hành.

Tuy nhiên, phạm vi TEE bảo vệ và phạm vi tin cậy của ứng dụng là khác nhau. Nếu trong Pod có ứng dụng chứa lỗ hổng thì TEE không che giấu lỗ hổng đó, cũng không ngăn được việc chiếm quyền do đầu vào độc hại. Do đó, phân tích lỗ hổng image, bảo mật ứng dụng, RBAC của Kubernetes và chính sách mạng phải được áp dụng cùng với CoCo.

Phân loại Ranh giới tin cậy Trách nhiệm chính
Vùng bảo mật Pod workload, guest helper hạn chế Thực thi ứng dụng và sử dụng bí mật
Tầng kiểm chứng Giá trị đo lường TEE, attestation agent Tạo bằng chứng về môi trường thực thi
Tầng cấp phát khóa KBS, attestation service, kho chính sách Kiểm chứng bằng chứng và quyết định chuyển bí mật
Vùng nền tảng Hypervisor, host, các Pod khác Lập lịch·cung cấp tài nguyên, về cơ bản không tin cậy
Vùng điều khiển API server, CI/CD, registry, nhà vận hành Phê duyệt triển khai·kiểm toán·thay đổi chính sách

3. Thành phần và luồng xử lý

A. Kiến trúc tổng thể

sequenceDiagram
    participant Dev as Developer or CI
    participant K8s as Kubernetes API
    participant Kata as Kata runtime and Pod VM
    participant TEE as TEE guest
    participant AS as Attestation service
    participant KBS as Key Broker Service
    participant Reg as Registry
    Dev->>K8s: Deploy Pod with RuntimeClass
    K8s->>Kata: Start confidential Pod VM
    TEE->>AS: Send hardware and guest evidence
    AS-->>KBS: Return appraisal result
    KBS->>TEE: Release image key and secrets
    TEE->>Reg: Pull encrypted or signed image
    TEE-->>K8s: Run workload and report status

Kata Containers, khác với container runtime thông thường, là tầng cách ly chạy Pod bên trong VM nhẹ. CoCo làm cho VM này chạy trên phần cứng TEE, và bổ sung vào bên trong guest các thành phần như trung tâm dữ liệu bảo mật (Confidential Data Hub) và agent chứng thực. Kata Agent quản lý vòng đời container bên trong guest, nên phải được bảo vệ cùng với chính sách guest để host không thể tùy ý quyết định các thao tác container của guest.

Attestation Agent tạo evidence (bằng chứng) để chứng minh trạng thái phần cứng và thực thi của guest. Evidence có thể chứa các giá trị cần cho phán đoán chính sách như loại TEE, giá trị đo lường image guest, dữ liệu khởi tạo, cấu hình runtime. Bên kiểm chứng không tin tưởng chỉ vì "có thông điệp chứng thực", mà phải xem xét chữ ký phần cứng, chuỗi chứng chỉ, giá trị đo lường được cho phép và mức bảo mật TCB.

Trong cấu hình thuộc dòng Trustee, Attestation Service kiểm chứng bằng chứng, còn Key Broker Service (KBS) phán đoán cấp bí mật nào cho workload nào. Confidential Data Hub làm trung gian cho các yêu cầu tài nguyên bí mật bên trong guest, để ứng dụng trong guest không phải tự triển khai giao thức KBS. Tách quyết định khỏi thực thi giúp KBS có thể thay đổi chính sách mà không phải build lại image workload, nhưng nhất thiết phải truy vết phiên bản chính sách và log quyết định.

B. Chứng thực từ xa và cấp phát khóa có điều kiện

Quy trình chứng thực thường theo thứ tự sau. Trước tiên, guest nhận một challenge có chứa nonce, và phần cứng TEE tạo bằng chứng đo lường của môi trường thực thi hiện tại. Tiếp đó, Attestation Service xác nhận chữ ký và chuỗi chứng chỉ của bằng chứng, rồi so sánh với appraisal policy và reference value của tổ chức. Nếu kết quả kiểm chứng đạt, KBS chuyển khóa image hoặc secret được yêu cầu theo điều kiện chính sách. Nếu thất bại thì không cấp khóa, nên dù có image mã hóa, guest chưa được phê duyệt cũng không thể bắt đầu công việc.

Chính sách cấp phát khóa không được đơn giản kiểu "là TEE thì cho phép". Cần lấy đồng thời làm điều kiện loại TEE, digest image guest, chính sách Kata Agent, digest image container, namespace, danh tính workload, thời điểm hết hạn và mục đích. Ví dụ, khóa trọng số mô hình vận hành chỉ được cho phép khi GPU TEE được phê duyệt và một digest image cụ thể cùng khớp, còn khóa dữ liệu phát triển có thể được giới hạn bằng một chính sách riêng cấp thấp hơn.

Chứng thực không phải là việc cấp chứng chỉ mà một lần vượt qua là tin tưởng mãi mãi. Phải kiểm chứng lại khi guest khởi động lại, image thay đổi, vá bảo mật TCB, khóa hết hạn, chính sách thay đổi, và cần thiết kế gia hạn session key và lease ngay cả khi dịch vụ chạy trong thời gian dài. Ngoài ra, không ghi nguyên dữ liệu cá nhân hay bí mật vào bằng chứng và log, mà tối thiểu hóa ở mức giá trị đo lường, phiên bản chính sách và kết quả quyết định cần cho kiểm chứng.

C. Bảo vệ image và secret

Image có chữ ký phù hợp để xác nhận image được tạo bởi nhà cung cấp được phê duyệt và chưa bị sửa đổi. Tuy nhiên, chỉ chữ ký thì không ngăn được nhà vận hành registry hay host đọc nội dung image. Khi bản thân image cần tính bí mật như trọng số mô hình hay dữ liệu kinh doanh, hãy mã hóa các lớp image và cấu hình để chỉ lấy khóa giải mã sau khi chứng thực thành công.

Trong phương thức guest pull của image mã hóa, runtime của host không thay mặt giải nén các lớp bản rõ. Guest nhận khóa từ KBS sau khi vượt qua chứng thực, rồi bên trong guest lấy image từ registry để giải mã·kiểm chứng·thực thi. Khi đó, nếu cấu trúc làm lộ thông tin xác thực registry cho host thì mục tiêu bảo vệ bị suy yếu, nên phạm vi và vị trí lưu token xác thực cũng phải phù hợp với vùng bảo mật.

Nếu tiêm nguyên Kubernetes Secret vào biến môi trường của Pod, nó có thể bị lộ lại qua log, core dump, công cụ gỡ lỗi. Do đó, secret được gắn với chính sách tài nguyên KBS và danh tính workload, và được chuyển dưới dạng thông tin xác thực ngắn hạn tại thời điểm tối thiểu cần cho runtime. Việc ứng dụng có cần giữ secret lâu hay có thể hủy ngay khỏi bộ nhớ cũng phải được quyết định cùng với chính sách phân loại dữ liệu.

D. Liên kết với Kubernetes

CoCo dùng cách chọn hồ sơ thực thi được bảo vệ bằng RuntimeClass. Ví dụ, Pod thông thường dùng runtime mặc định, chỉ các Pod nhạy cảm được đặt vào lớp như kata-qemu-snp hoặc kata-qemu-tdx. Bộ lập lịch phải xét nhãn và điều kiện tài nguyên của node hỗ trợ TEE; nếu bị đặt vào sai node thì có thể xảy ra thất bại triển khai hoặc thực thi không bảo mật ngoài ý muốn.

Chính sách Admission phải kiểm tra image được phép, RuntimeClass bắt buộc, tùy chọn gỡ lỗi bị cấm, nhãn node, namespace và service account. Tính bí mật của CoCo dễ bị phá vỡ nếu tách kiểu chỉ đưa Pod ứng dụng vào TEE còn sidecar·init container để ở runtime thông thường. Cần rà soát mọi container và các bước khởi tạo của toàn Pod trong cùng một ranh giới bảo vệ, và các ngoại lệ phải được lưu thành đối tượng chính sách có người phê duyệt, thời hạn và lý do.

4. Phương thức triển khai và so sánh

A. Pod VM cục bộ và Peer Pods

Phương thức Pod VM cục bộ tạo Kata VM trên node của cluster, sử dụng bare metal có CPU hỗ trợ TEE hoặc môi trường ảo hóa phù hợp. Ưu điểm là có thể trực tiếp quản lý tài nguyên node, nhưng phải vận hành ảo hóa lồng nhau, passthrough thiết bị, thay thế node và tương thích firmware TEE.

Trong phương thức Peer Pods, Cloud API Adaptor gọi API đám mây thay cho hypervisor thông thường của node cluster hiện có để tạo VM bên ngoài có kích hoạt TEE. Do đó, giảm nhu cầu node cluster phải là bare metal TEE, và có thể tận dụng dịch vụ confidential VM của đám mây. Ngược lại, phải quản lý thêm độ trễ tạo Pod, sự phụ thuộc vào API đám mây, kết nối mạng·storage của VM bên ngoài, chi phí và miền sự cố.

Tiêu chí so sánh Pod VM cục bộ Peer Pods
Vị trí tạo VM Kubernetes worker node VM bên ngoài do API đám mây tạo
Ưu điểm Phụ thuộc bên ngoài thấp, kiểm soát node chi tiết Áp dụng vào cluster hiện có, tận dụng TEE của CSP
Gánh nặng chính Quản lý node·firmware·thiết bị TEE Độ trễ API·mạng·chi phí VM bên ngoài
Môi trường phù hợp On-premise·biên được kiểm soát Đám mây công cộng·đa tenant
Rủi ro chung Phải thiết kế riêng chính sách chứng thực, cấp phát khóa, bảo vệ image Phải thiết kế riêng chính sách chứng thực, cấp phát khóa, bảo vệ image

B. So sánh container truyền thống, Kata và CoCo

Container truyền thống dùng chung kernel host nên tốc độ khởi động và mật độ cao, nhưng không đảm bảo tính bí mật đối với quản trị viên host. Kata Containers thông thường tách host và container bằng cách ly VM, nhưng image và các thành phần guest không phải lúc nào cũng gắn với chứng thực từ xa và cấp phát khóa. CoCo bổ sung TEE phần cứng và chuyển giao bí mật có điều kiện vào ranh giới VM của Kata để hiện thực chính sách "nếu không kiểm chứng được mã và môi trường đang chạy thì không lấy được bí mật".

Đổi lại, CoCo có chi phí khởi động VM·chứng thực·trao đổi khóa và độ phức tạp vận hành cao hơn container thông thường. Mạng hiệu năng cao, GPU, CSI storage, công cụ gỡ lỗi·quan sát có thể xung đột với ranh giới TEE, nên việc chuyển mọi nghiệp vụ sang CoCo một cách vô điều kiện là không hợp lý. Chọn hồ sơ bảo vệ theo mức độ nhạy cảm của dữ liệu và mức độ đe dọa từ nhà cung cấp, và vận hành hỗn hợp container thông thường·Kata·CoCo là phù hợp với cân bằng giữa chi phí và bảo mật.

5. Tình huống áp dụng

Giả sử một tổ chức tài chính cùng phân tích đặc trưng giao dịch của nhiều tổ chức. Mỗi tổ chức không muốn để lộ dữ liệu gốc cho nhà vận hành đám mây bên ngoài nhưng muốn chia sẻ kết quả phân tích. Đặt đầu vào mã hóa của từng tổ chức và image phân tích được phê duyệt vào CoCo, KBS chỉ cung cấp khóa giải mã dữ liệu khi giá trị đo lường TEE, digest image và mục đích phân tích đều khớp. Kết quả phân tích được áp dụng giới hạn phạm vi đầu ra, chống tái định danh và giới hạn tần suất truy vấn, để rủi ro dữ liệu cá nhân ở giai đoạn kết quả không biến mất chỉ vì có TEE.

Tình huống thứ hai là bảo vệ mô hình AI của doanh nghiệp sản xuất. Dịch vụ suy luận sử dụng GPU đám mây bên ngoài, nhưng trọng số mô hình là tài sản cốt lõi trước đối thủ cạnh tranh nên nhà vận hành node không được đọc được. Khi dùng CoCo cùng GPU TEE, có thể xem xét cấu hình composite attestation mã hóa image mô hình và dữ liệu đầu vào, chỉ cấp khóa mô hình khi giá trị đo lường của cả GPU·CPU đều được phê duyệt. Tuy nhiên, GPU passthrough, driver, phiên bản CUDA, bộ nạp mô hình đều thuộc TCB và tiêu chí chứng thực, nên cần có trước ma trận hỗ trợ và build có thể tái tạo.

Tình huống thứ ba là cách ly tenant của nhà cung cấp SaaS. Pod phân tích dùng chung xử lý tài liệu nhạy cảm của từng tenant được chạy trên CoCo, và khóa tenant được gắn với danh tính tenant, mục đích xử lý và lease ngắn hạn. Chức năng exec vào Pod của nhà vận hành không được cho phép như môi trường vận hành thông thường, chỉ cung cấp image gỡ lỗi được phê duyệt và kênh chẩn đoán đã che dữ liệu. Cấu trúc này giảm sự tin cậy vào nhà cung cấp hạ tầng, nhưng không thay thế việc kiểm chứng quyền của chính ứng dụng SaaS và cách ly logic giữa các tenant.

6. Nâng cao — Mức độ trưởng thành và chiến lược trình bày bài làm

CoCo là dự án mã nguồn mở nhằm trừu tượng hóa khác biệt triển khai TEE theo phần cứng thành mô hình workload của Kubernetes. Khi áp dụng thực tế, CPU·GPU sử dụng, nhà cung cấp đám mây, runtime Kata, cấu hình Trustee, khả năng hỗ trợ CSI và mạng có thể khác nhau theo phiên bản, nên phải kiểm chứng dựa trên release note chính thức và bảng hỗ trợ phần cứng. Không được hiểu nhầm "chức năng tùy chọn" trong tài liệu là bảo đảm vận hành, mà phải xác nhận image mã hóa, kiểm chứng chữ ký, chứng thực từ xa, Peer Pods bằng PoC và thử nghiệm sự cố riêng cho từng thứ.

Trong bài làm Kỹ sư chuyên nghiệp (Professional Engineer), nên nêu trước vấn đề "chỉ mã hóa lưu trữ·truyền tải thì không bảo vệ được data in use". Tiếp theo giải thích ranh giới tin cậy Pod-centric và TEE, rồi trình bày bằng sơ đồ khái niệm luồng xử lý theo thứ tự Kata runtime → attestation → KBS → encrypted image. Sau đó so sánh container truyền thống·Kata·CoCo theo tiêu chí tính bí mật, tính toàn vẹn, hiệu năng, độ khó vận hành. Cuối cùng, liên kết chính sách cấp phát khóa, chuỗi cung ứng, khả năng quan sát, phê duyệt ngoại lệ, kiểm chứng hiệu năng thành các điểm cần lưu ý theo góc nhìn Kỹ sư chuyên nghiệp thì tính hoàn chỉnh của bài luận sẽ cao hơn.

Đặc biệt tránh cách diễn đạt "TEE ngăn chặn mọi cuộc tấn công". TEE cung cấp ranh giới phần cứng mạnh bảo vệ bộ nhớ và trạng thái thực thi khỏi host, nhưng không tự động giải quyết lỗ hổng ứng dụng, image độc hại, chính sách khóa không phù hợp, log bất cẩn hay tấn công từ chối dịch vụ. Bảo đảm bảo vệ chỉ được thiết lập khi phần cứng, image guest, chính sách runtime, chuỗi cung ứng image và chính sách KBS được nối thành một chuỗi có thể kiểm chứng.

7. Các điểm cần lưu ý và hàm ý

A. Tối thiểu hóa TCB và tiêu chí đo lường

Tối thiểu hóa kernel guest, Kata Agent, dữ liệu khởi tạo, driver, thành phần GPU thuộc TCB, và quản lý phiên bản cùng hash build của từng thành phần. Nếu mỗi khi giá trị đo lường thay đổi đều dừng triển khai vô điều kiện thì việc vá lỗi trở nên khó khăn, ngược lại nếu cho phép mọi giá trị đo lường thì chứng thực mất ý nghĩa. Thay đổi danh sách cho phép phải qua rà soát bảo mật và quy trình rollback, và cần vận hành appraisal policy phân biệt bản vá khẩn cấp với phát hành thông thường.

B. Quản lý khóa và tách biệt chính sách

KBS không phải là kho bí mật đơn thuần mà là điểm thực thi chính sách đánh giá bằng chứng. Gắn khóa với digest image, danh tính workload, mục đích, môi trường, thời điểm hết hạn, và thiết kế phân cấp khóa sao cho ngay cả quản trị viên cũng không thấy được khóa bản rõ. Tách người soạn chính sách với người vận hành khóa, lưu thay đổi chính sách, cấp phát khóa và lý do thất bại vào log kiểm toán nhưng không để bí mật lẫn vào chính log.

C. Chuỗi cung ứng và khả năng tái tạo

Build image guest và image container theo cách có thể tái tạo, và liên kết SBOM, chữ ký, kiểm tra lỗ hổng, chứng minh nguồn gốc vào CI/CD. Chữ ký bổ sung tính toàn vẹn và nguồn gốc nhưng không cung cấp tính bí mật, nên khi cần thì dùng cùng image mã hóa. Xem xét lấy làm mặc định chính sách fail-closed: không cấp khóa nếu digest image mà KBS cho phép không khớp với hồ sơ phê duyệt của pipeline triển khai.

D. Hiệu năng, tính sẵn sàng và chế độ sự cố

Chứng thực và trao đổi khóa gây thêm độ trễ cho thời gian khởi động Pod. Phản ánh độ trễ khởi động, lượt đi về registry, sự cố KBS, thiếu tài nguyên TEE vào SLO, và dù dùng cache khóa cũng phải giới hạn phạm vi và thời hạn của khóa được cache. Quyết định trước việc khi KBS hoặc Attestation Service tạm thời lỗi thì có xử lý khác nhau giữa tiếp tục chạy Pod hiện có và khởi động Pod mới hay không, và có cho phép fail-open khi sự cố hay không.

E. Khả năng quan sát và gỡ lỗi

Nếu vì lý do bảo mật mà hoàn toàn không ghi dữ liệu vận hành thì không thể ứng phó sự cố. Ghi có cấu trúc, không chứa thông tin nhạy cảm, các mục chứng thực thành công·thất bại, phiên bản chính sách, digest image, runtime class, kết quả cấp phát khóa, và giới hạn truy cập log theo đặc quyền tối thiểu. An toàn hơn là mặc định từ chối memory dump và exec từ xa, đồng thời cung cấp riêng môi trường không bảo mật để tái hiện và image chẩn đoán được phê duyệt.

F. Quy định và ranh giới trách nhiệm

CoCo tăng cường biện pháp bảo vệ kỹ thuật cho dữ liệu cá nhân, tài chính, y tế, nhưng không thay thế căn cứ pháp lý để xử lý và giới hạn mục đích. Cần ghi rõ trong hợp đồng và quy trình vận hành ai sở hữu chính sách chứng thực, ai phê duyệt reference value, trách nhiệm của nhà cung cấp phần cứng và nhà cung cấp đám mây đến đâu. Trong kiểm toán, thay vì chỉ nói có dùng TEE hay không, cần liên kết phân loại dữ liệu, căn cứ cấp phát khóa, phê duyệt ngoại lệ, hồ sơ hủy và khôi phục để giải thích tính hiệu lực của biện pháp kiểm soát.

Tóm tắt một câu: Confidential Containers là phương thức điện toán bảo mật ở mức thực thi, kết nối cách ly Pod dựa trên Kata với TEE phần cứng, chứng thực từ xa và cấp phát khóa có điều kiện, để bảo vệ dữ liệu đang sử dụng và workload của Kubernetes ngay cả trên hạ tầng không tin cậy.

Tài liệu tham khảo