Attestation and Key-Release Flow#
Attestation is the point where the business agreement becomes enforceable. The model provider doesn’t release the key because a pod asked for it; the key is released because the workload proved it’s the approved image, in the approved confidential runtime, on approved hardware, with approved policy state.
The end-to-end flow:
The model provider builds and signs the workload image.
The model provider encrypts model artifacts and defines key-release policy.
The CC software provider and platform operator register reference values for the guest, runtime policy, workload image, GPU state, and target environment.
The platform operator prepares the Kubernetes cluster, confidential GPU node pool, firmware, GPU Operator path, and confidential runtime class.
Kubernetes schedules the pod to an eligible node using the confidential runtime class.
Kata launches the pod inside a measured confidential VM.
Confidential Data Hub requests the model secret from KBS.
The Attestation Agent obtains a fresh verifier nonce and produces attestation evidence for CPU, GPU, guest, workload, runtime policy, and identity.
KBS validates the evidence with the Attestation Service, reference values, collateral, and policy.
KBS releases the model key into the confidential guest over a secure channel.
The workload reads model artifacts inside protected memory.
The inference service starts accepting approved HTTPS traffic.
Figure 5 Attestation and key release workflow#
The verifier rejects stale evidence, unexpected firmware, unexpected guest measurements, unexpected runtime policy, disabled security features, revoked collateral, or unapproved GPU state. The verifier-provided nonce is part of the evidence check, so a captured response can’t be replayed.