Red Hat SummitChapter 1. Discover
You can deploy Red Hat build of Trustee for confidential containers workloads running on bare-metal servers with the Intel® Trust Domain Extensions (TDX) or AMD SEV-SNP Trusted Execution Environments (TEEs). Red Hat build of Trustee provides attestation and key management services for confidential workloads running with Trusted Execution Environments (TEEs) on a Red Hat OpenShift Container Platform cluster.
You deploy Red Hat build of Trustee on a separate OpenShift Container Platform cluster in a trusted environment, not on the cluster that hosts the primary workload. This separation enhances security by isolating sensitive operations from the untrusted cloud infrastructure.
Red Hat build of Trustee performs the following key functions:
- Verifies the integrity of the TEE and the workloads running within it, ensuring that it only executes trusted code and data.
- Securely manages cryptographic keys and secrets required by confidential containers, protecting sensitive data from unauthorized access.
-
Simplifies the configuration of TEEs through the
TrusteeConfigcustom resource, enabling seamless integration with OpenShift Container Platform workflows.
By leveraging Red Hat build of Trustee, OpenShift Container Platform users can deploy confidential workloads using familiar tools while maintaining strong security guarantees, even on shared or third-party infrastructure.
1.1. Common terms
The following terms are used throughout the documentation.
- Attestation
- The process of verifying the integrity and trustworthiness of a Trusted Execution Environment (TEE) and the confidential containers workloads running within it, ensuring that only trusted code and data are executed. Red Hat build of Trustee performs this function.
- Confidential containers
- A technology that provides a confidential computing environment to protect containers and data by leveraging Trusted Execution Environments.
- Initdata
- A specification used to securely initialize a pod with workload-specific data (such as certificates, cryptographic keys, or an optional Kata Agent policy) at runtime, preventing the need to embed this data directly in the virtual machine (VM) image.
- Kata Agent
- A component within the pod Virtual Machine (VM) that enforces runtime policies and manages the lifecycle of the containers running inside the VM. Its policy controls API requests for peer pods.
- Kata containers
- Kata containers is a core upstream project that is used to build OpenShift sandboxed containers. OpenShift sandboxed containers integrate Kata containers with OpenShift Container Platform.
kataruntime- The optional runtime installed by the OpenShift sandboxed containers Operator when configuring bare metal deployments.
kata-ccruntime- The runtime class used specifically for confidential containers deployments on bare-metal servers.
kata-remoteruntime- The runtime class used for peer pod deployments on cloud platforms or remote hypervisors.
KataConfig- A custom resource used to configure and launch OpenShift sandboxed containers.
TrusteeConfig- A custom resource used to configure and launch Red Hat build of Trustee.
- OpenShift sandboxed containers
- OpenShift sandboxed containers integrates Kata containers as an optional runtime to provide enhanced security and isolation for container workloads by running applications in lightweight virtual machines.
- OpenShift sandboxed containers Operator
- The OpenShift sandboxed containers Operator manages the lifecycle of OpenShift sandboxed containers and confidential containers on a cluster.
- Peer pod
A peer pod in OpenShift sandboxed containers extends the concept of a standard pod. Unlike a standard sandboxed container, where the virtual machine is created on the worker node itself, in a peer pod, the virtual machine is created through a remote hypervisor using any supported hypervisor or cloud provider API.
The peer pod acts as a regular pod on the worker node, with its corresponding VM running elsewhere. The remote location of the VM is transparent to the user and is specified by the runtime class in the pod specification. The peer pod design circumvents the need for nested virtualization.
- Pod
A pod is a construct that is inherited from Kubernetes and OpenShift Container Platform. It represents resources where containers can be deployed. Containers run inside pods, and pods are used to specify resources that can be shared between multiple containers.
In the context of OpenShift sandboxed containers, a pod is implemented as a virtual machine. Several containers can run in the same pod on the same virtual machine.
- Red Hat build of Trustee
- Red Hat build of Trustee is an attestation service that verifies the trustworthiness of the location where you plan to run your workload or where you plan to send confidential information. Red Hat build of Trustee includes components deployed on a trusted side and used to verify whether the remote workload is running in a Trusted Execution Environment (TEE).
- Red Hat build of Trustee Operator
- The Red Hat build of Trustee Operator manages the installation, lifecycle, and configuration of Red Hat build of Trustee.
- Runtime class
- An object that describes the specific runtime configuration used to execute a workload.
- Sandbox
A sandbox is an isolated environment where programs can run. In a sandbox, you can run untested or untrusted programs without risking harm to the host machine or the operating system.
In the context of OpenShift sandboxed containers, sandboxing is achieved by running workloads in a different kernel using virtualization, providing enhanced control over the interactions between multiple workloads that run on the same host.
- Trusted Execution Environment (TEE)
- Hardware-based security technology leveraged by confidential containers to protect containers and data. Examples: Intel® TDX, AMD SEV-SNP.
1.2. Overview of NVIDIA GPU attestation with Trustee
You can verify the integrity and authenticity of NVIDIA graphics processing unit (GPU) hardware and firmware for confidential containers by using Red Hat build of Trustee with NVIDIA Remote Attestation Service (NRAS). GPU attestation ensures AI and ML workloads run only on trusted, authenticated GPU hardware.
NVIDIA GPU attestation is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.
- How GPU attestation works
GPU attestation extends Red Hat build of Trustee capabilities beyond CPU-based Trusted Execution Environments (TEEs) to include GPU accelerator hardware verification. When you deploy confidential containers with GPU resources, Red Hat build of Trustee can verify that the GPU firmware and hardware have not been tampered with before allowing workloads to access GPU resources.
For NVIDIA GPUs with Confidential Computing capabilities, Red Hat build of Trustee integrates with NVIDIA Remote Attestation Service (NRAS) to perform attestation. NRAS is a cloud-based attestation service operated by NVIDIA that maintains reference values for GPU firmware measurements and validates GPU attestation evidence.
- NVIDIA Remote Attestation Service (NRAS) role
NVIDIA Remote Attestation Service (NRAS) provides the following capabilities:
- Centralized reference value management: NVIDIA maintains and updates reference measurement values for GPU firmware, eliminating the need to manually collect and configure GPU measurement hashes.
- Remote verification: NRAS validates GPU attestation evidence in the cloud and returns verification results to Red Hat build of Trustee.
- Firmware version tracking: NRAS database includes measurements for different GPU firmware versions and configurations.
- Trustee as NRAS proxy
Red Hat build of Trustee acts as a proxy between confidential containers and NRAS. This proxy model keeps guest workloads isolated from direct internet access while enabling GPU attestation.
The attestation flow works as follows:
- A confidential container with GPU resources requests a secret from Red Hat build of Trustee and provides attestation evidence including GPU measurements.
- Red Hat build of Trustee receives the attestation request.
- Red Hat build of Trustee forwards GPU attestation evidence to NRAS for verification.
- NRAS validates GPU measurements against its reference database and returns verification results.
- Red Hat build of Trustee evaluates the attestation policy based on NRAS verification results.
- If attestation succeeds, Red Hat build of Trustee releases the requested secret to the confidential container.
- Verifier modes
- The NVIDIA verifier in Red Hat build of Trustee supports two operational modes:
- Remote verifier mode
- Red Hat build of Trustee forwards GPU attestation evidence to NRAS for remote verification. NRAS compares GPU measurements against its internal reference database. You do not configure GPU measurement hashes manually. This mode requires network connectivity to NVIDIA cloud services.
- Local verifier mode
Red Hat build of Trustee validates GPU measurements directly without contacting NRAS. You must configure expected GPU measurement hashes in the Reference Value Provider Service (RVPS) config map. This mode does not require network connectivity to NVIDIA cloud services.
NoteLocal verifier mode is not supported in OpenShift sandboxed containers 1.12. Use remote verifier mode for GPU attestation.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}