From dd4c460010a5347e12b620aee04b727c58c213cf Mon Sep 17 00:00:00 2001 From: Tom Dohrmann Date: Tue, 10 Sep 2024 10:04:43 +0200 Subject: [PATCH] docs: mention TDX in architecture descriptions Everywhere we mention specifics on SNP, we should also mention the correspondings specifics for TDX. --- docs/docs/architecture/attestation.md | 6 +++--- docs/docs/components/policies.md | 10 +++++----- docs/docs/components/runtime.md | 2 +- 3 files changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/docs/architecture/attestation.md b/docs/docs/architecture/attestation.md index 6674e06ec..662b38f33 100644 --- a/docs/docs/architecture/attestation.md +++ b/docs/docs/architecture/attestation.md @@ -39,8 +39,8 @@ The root filesystem contains all components of the container's runtime environm In the userland, the guest agent takes care of enforcing the [runtime policy](../components/overview.md#runtime-policies) of the pod. While the policy is passed in during the initialization procedure via the host, the evidence for the runtime policy is part of the CPU measurements. During the [deployment](../deployment.md#generate-policy-annotations-and-manifest) the policy is annotated to the Kubernetes Pod resources. -On AMD SEV-SNP the hash of the policy is then added to the attestation report via the `HOSTDATA` field by the hypervisor. -When provided with the policy from the Kata host, the guest agent verifies that the policy's hash matches the one in the `HOSTDATA` field. +The hypervisor adds the hash of the policy to the attestation report via the HOSTDATA (on AMD SEV-SNP) or MRCONFIGID (Intel TDX) fields. +When provided with the policy from the Kata host, the guest agent verifies that the policy's hash matches the one in the `HOSTDATA`/`MRCONFIGID` field. In summary a Pod's evidence is the attestation report of the CPU that provides evidence for runtime environment and the runtime policy. @@ -92,7 +92,7 @@ By validating the runtime environment and the policies enforced on it, Contrast ### How does Contrast ensure the security of the attestation process? -Contrast leverages hardware-rooted security features such as AMD SEV-SNP to generate cryptographic evidence of a pod’s current state and configuration. +Contrast leverages hardware-rooted security features such as AMD SEV-SNP or Intel TDX to generate cryptographic evidence of a pod’s current state and configuration. This evidence is checked against pre-defined appraisal policies to guarantee that only verified and authorized pods are part of a Contrast deployment. ### What security benefits does attestation provide? diff --git a/docs/docs/components/policies.md b/docs/docs/components/policies.md index dbffdd2db..1932280e5 100644 --- a/docs/docs/components/policies.md +++ b/docs/docs/components/policies.md @@ -36,10 +36,10 @@ These constitute the policy's *OCI data*. ## Evaluation The generated policy document is annotated to the pod definitions in Base64 encoding. -This annotation is propagated to the Kata runtime, which calculates the SHA256 checksum for the policy and uses that as SNP `HOSTDATA` for the confidential micro-VM. +This annotation is propagated to the Kata runtime, which calculates the SHA256 checksum for the policy and uses that as SNP `HOSTDATA` or TDX `MRCONFIGID` for the confidential micro-VM. After the VM launched, the runtime calls the agent's `SetPolicy` method with the full policy document. -If the policy doesn't match the checksum in `HOSTDATA`, the agent rejects the policy. +If the policy doesn't match the checksum in `HOSTDATA` or `MRCONFIGID`, the agent rejects the policy. Otherwise, it applies the policy to all future `AgentService` requests. ## Guarantees @@ -66,12 +66,12 @@ Contrast verifies its confidential containers following these steps: 1. The Contrast CLI generates a policy and attaches it to the pod definition. 2. Kubernetes schedules the pod on a node with the confidential computing runtime. 3. Containerd invokes the Kata runtime to create the pod sandbox. -4. The Kata runtime starts a CVM with the policy's digest as `HOSTDATA`. +4. The Kata runtime starts a CVM with the policy's digest as `HOSTDATA`/`MRCONFIGID`. 5. The Kata runtime sets the policy using the `SetPolicy` method. -6. The Kata agent verifies that the incoming policy's digest matches `HOSTDATA`. +6. The Kata agent verifies that the incoming policy's digest matches `HOSTDATA`/`MRCONFIGID`. 7. The CLI sets a manifest in the Contrast Coordinator, including a list of permitted policies. 8. The Contrast Initializer sends an attestation report to the Contrast Coordinator, asking for a mesh certificate. -9. The Contrast Coordinator verifies that the started pod has a permitted policy hash in its `HOSTDATA` field. +9. The Contrast Coordinator verifies that the started pod has a permitted policy hash in its `HOSTDATA`/`MRCONFIGID` field. After the last step, we know that the policy hasn't been tampered with and, thus, that the workload matches expectations and may receive mesh certificates. diff --git a/docs/docs/components/runtime.md b/docs/docs/components/runtime.md index a0be9e304..b40992b6a 100644 --- a/docs/docs/components/runtime.md +++ b/docs/docs/components/runtime.md @@ -31,7 +31,7 @@ spec: ## Node-level components The runtime consists of additional software components that need to be installed -and configured on every SEV-SNP-enabled worker node. +and configured on every SEV-SNP-enabled/TDX-enabled worker node. This installation is performed automatically by the [`node-installer` DaemonSet](#node-installer-daemonset). ![Runtime components](../_media/runtime.svg)