Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
75 changes: 60 additions & 15 deletions confidential-containers/supported-platforms.rst
Original file line number Diff line number Diff line change
Expand Up @@ -28,7 +28,7 @@ This page is relevant to the following users:

* The :ref:`Hardware IT Administrator <coco-persona-hardware-it-administrator>` uses the hardware tables to confirm that the selected CPU and GPU are validated for Confidential Computing before configuring the system.
* The :ref:`Host OS Administrator <coco-persona-host-os-administrator>` uses the hardware tables to confirm validated host OS and kernel versions.
* The :ref:`Kubernetes Cluster Administrator <coco-persona-kubernetes-cluster-administrator>` uses the software component matrix to confirm that the correct versions are in place before beginning cluster installation.
* The :ref:`Kubernetes Cluster Administrator <coco-persona-kubernetes-cluster-administrator>` uses the component matrix to confirm supported versions.

********
Hardware
Expand Down Expand Up @@ -75,16 +75,16 @@ NVIDIA GPUs
For both single and multi GPU Passthrough, all GPUs on the host must be configured for Confidential Computing and all GPUs must be assigned to one Confidential Container virtual machine.
Configuring only some GPUs on a node for Confidential Computing is not supported.

CPU Platforms
=============
Host Platforms
==============

.. flat-table::
:header-rows: 1

* - Category
* - CPU Platform
- TEE
- Operating System
- Kernel Version
- Host Operating System
- Host Kernel Version
* - AMD Genoa / Milan
- AMD SEV-SNP
Comment on lines 88 to 89

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@manuelh-dev , I think you proposed removing this information or moving it. I took a look at the page and my instinct is to keep it:

  • It's not a disaster as it is. (Yay!)
  • I suspect the CPUs and technology are not yet widely prevalent and highlighting the required CPU features seems important. (For now.)
  • I suspect it meets expectations--that there would be a matrix for CPUs.

@manuelh-dev manuelh-dev Aug 25, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mikemckiernan - my suggestion was to move the Host Kernel Version and Host Operating System fields, specifically, down into the list below - but after your re-organization below, I think we are good. Agree that we can keep this information here

- Ubuntu 25.10 or 26.04
Expand Down Expand Up @@ -115,11 +115,44 @@ For additional resources on machine setup:
Supported Software Components
*****************************

Cluster and Deployment Software
================================

The installation guides begin with an existing Kubernetes cluster that uses ``containerd``.
You then install Kata Containers and the NVIDIA GPU Operator.

.. flat-table::
:header-rows: 1

* - Component
- Release/Version
- Installation
* - `Kubernetes <https://kubernetes.io/>`__
- 1.32 \+
- Prerequisite, must already be installed on the cluster hosts.
* - `containerd <https://github.com/containerd/containerd>`__
- 2.3.x
- Prerequisite, must already be installed on the cluster hosts.
* - `Kata Containers <https://katacontainers.io/>`__
- ${kata_version}
- Installed with the ``kata-deploy`` Helm chart by following the :doc:`Quickstart Install <install-quickstart>` or :doc:`Detailed Install Guide <confidential-containers-deploy>`.
* - `NVIDIA GPU Operator <https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/index.html>`__ and its components.

Refer to the :ref:`GPU Operator Component Matrix <gpuop:operator-component-matrix>` for the list of components and versions included in each release.
- ${gpu_operator_version} and higher
- Installed by following the :doc:`Quickstart Install <install-quickstart>` or :doc:`Detailed Install Guide <confidential-containers-deploy>`.

Kata-provided Guest and Runtime Artifacts
=========================================

The supported ``kata-deploy`` Helm chart installs the guest OS, guest kernel, OVMF, and QEMU artifacts listed in the following table as part of Kata Containers.
You do not supply or install these artifacts individually.

.. flat-table::
:header-rows: 1

* - Artifact
- Release/Version
* - Guest OS
- Distroless
* - Guest kernel
Expand All @@ -128,19 +161,31 @@ Supported Software Components
- edk2-stable202511
* - `QEMU <https://www.qemu.org/>`__
- 10.1 \+ Patches
* - `Containerd <https://github.com/containerd/containerd>`__
- 2.3.x
* - `Kubernetes <https://kubernetes.io/>`__
- 1.32 \+
* - `NVIDIA GPU Operator <https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/index.html>`__ and its components.

Refer to the :ref:`GPU Operator Component Matrix <gpuop:operator-component-matrix>` for the list of components and versions included in each release.
- ${gpu_operator_version} and higher
* - `Kata Containers <https://katacontainers.io/>`__
- ${kata_version} (installed with ``kata-deploy`` Helm chart)
Separately Deployed Components and Interfaces
=============================================

The following components and interfaces are not installed by the :doc:`Quickstart Install <install-quickstart>` or :doc:`Detailed Install Guide <confidential-containers-deploy>`.

.. flat-table::
:header-rows: 1

* - Interface or Component

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mikemckiernan - if or as we make this change, we could also list genpolicy - we should then merge #479 after this one.

- Version
- When It Is Needed
- How It Is Provided
* - `Key Broker Service (KBS) protocol <https://confidentialcontainers.org/docs/attestation/>`__

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fitzthum @fidencio - I think we need a bit of a refinement here. I think the KBS protocol is installed implicitly by shipping the attestation agent, CDH in our guests. So, I think here we want to say that trustee is not installed - and provide a specific trustee version to install, instead.

Then, in above listing for Kata Containers we can say that this comes with a guest using the 0.4.0 KBS protocol. This may make it easier here in turn because we can say to install a trustee version using that same protocol version (or, a protocol version that is compatible, if a patch version increment of the protocol version means that both are still interoperable).

- 0.4.0
- Required for Trustee-based attestation and secret or key release.
- The :doc:`Attestation <attestation>` quickstart installs a local evaluation Trustee.
Deploy a production Trustee separately by following the upstream Confidential Containers documentation.
* - `Kata Lifecycle Manager <https://github.com/kata-containers/lifecycle-manager>`__
- 0.1.8
- Optional for Kata Containers upgrades and day-two lifecycle management.
- Install separately by following the upstream Kata Lifecycle Manager documentation.
* - `Kata Containers genpolicy <https://github.com/kata-containers/kata-containers/blob/${kata_version}/src/tools/genpolicy/README.md>`__
- ${kata_version}
- Used to generate an agent security policy for attested production workloads.
- Download separately from the corresponding Kata Containers release.

Users may leverage `Red Hat OpenShift Sandboxed Containers <https://docs.redhat.com/en/documentation/openshift_sandboxed_containers/1.13>`__ to deploy Confidential Containers.