Appendix C. Component Responsibilities and Interfaces#
Table 11: Component Responsibilities
Component |
Generic role |
Reference implementation |
|---|---|---|
TEE-capable CPU |
VM-based trusted execution |
AMD SEV-SNP or Intel TDX on a validated server platform |
CC-capable GPU |
GPU attestation, secure GPU session, GPU memory protection |
NVIDIA GPU with CC mode enabled |
Kubernetes platform |
Admission, scheduling, RuntimeClass, RBAC, service discovery, network policy, and operations |
Validated Kubernetes platform |
Confidential runtime class |
Selects the handler that launches the pod inside a measured confidential VM |
Confidential containers runtime |
Confidential guest |
Attestation Agent, Confidential Data Hub, Kata Agent policy, model server, and secure GPU session |
Kata-based confidential guest with Trustee guest components |
Attestation verifier |
Validates CPU, GPU, guest, image, runtime-policy, nonce, and policy evidence |
Attestation Service |
Key broker or KMS |
Releases or unwraps model keys after attestation and policy evaluation |
KBS with KMS/HSM integration |
Encrypted model artifact store |
Stores model artifacts without exposing unencrypted artifacts to the node or cluster |
Registry, object store, or encrypted volume |
Inference endpoint |
Narrow HTTPS endpoint exposed by the confidential pod to approved callers |
Kubernetes Service, route, gateway, or load balancer |
Table 12: Component Interfaces
Interface |
Producer |
Consumer |
Requirement |
Required operator signal |
|---|---|---|---|---|
Pod admission and scheduling |
Kubernetes API, scheduler, RuntimeClass, node labels |
Platform operator, runtime, verifier |
RuntimeClass, node selector, GPU request, namespace, service account, image digest, policy annotations |
Admission, scheduling, or runtime-class failure naming the unsupported setting |
Confidential sandbox launch |
Kata runtime and worker node |
Platform operator, verifier |
Guest image/initrd, runtime policy, CPU TEE flags, GPU assignment, pod identity, network devices |
Sandbox launch success/failure naming runtime, node, guest, or device reason |
Attestation evidence |
Guest Attestation Agent and GPU attestation component |
Attestation Service, KBS, key-release authority |
Evidence formats, nonce/freshness rules, CPU TEE claims, GPU claims, guest, image, and runtime-policy measurements |
Pass/fail decision with claim, collateral, or reference-value reason |
Reference values |
Reference value or policy store |
Attestation Service, KBS, model provider |
Measurement registration process, policy version, collateral source, expiry and revocation handling |
Policy version and reference-value ID in logs and audits |
Key release |
KBS and KMS/HSM |
Confidential pod bootstrap or workload |
Secret identity, requester identity, allowed measurements, release channel, audit fields |
Release, deny, or dependency error with key ID, request ID, policy version |
Artifact access |
Registry, object store, or encrypted volume |
Confidential pod workload |
Artifact digest, encryption method, signature/provenance, fetch identity, cache behavior |
Fetch/decrypt success or denial without payload exposure |
Service endpoint |
Pod, Service, Route, gateway, load balancer |
Enterprise clients, platform operator |
HTTPS endpoint, health endpoint, certificates, DNS, allowed callers, blocked admin paths |
Connection, health, or certificate error naming the boundary without exposing payloads |
Observability |
Kubernetes, worker node, confidential guest, Trustee, KBS, GPU components |
Platform operator, SIEM, security team |
Event schema, severity, correlation ID, retention, escalation path |
Error class, request ID, policy version, component ID; no prompts, responses, keys, or model data |