diff --git a/confidential-containers/README.md b/confidential-containers/README.md new file mode 100644 index 000000000..d08a93fba --- /dev/null +++ b/confidential-containers/README.md @@ -0,0 +1,8 @@ +# Confidential Containers Documentation Migrated + +The confidential containers documentation is now in the https://github.com/NVIDIA/confidential-computing-docs repo. +Open new issues and pull requests in that repo. + +The documentation is served from https://docs.nvidia.com/confidential-computing/containers. +The v1.0.0 and v1.1.0 release content is preserved. +Redirects from https://docs.nvidia.com/datacenter/cloud-native/confidential-containers are in place. diff --git a/confidential-containers/attestation.rst b/confidential-containers/attestation.rst deleted file mode 100644 index 61a36da1c..000000000 --- a/confidential-containers/attestation.rst +++ /dev/null @@ -1,287 +0,0 @@ -.. license-header - SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. - SPDX-License-Identifier: Apache-2.0 - - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - -.. headings # #, * *, =, -, ^, " - - -*********** -Attestation -*********** - -As a :ref:`Security Engineer `, use this page to understand attestation concepts and stand up a local Trustee instance for testing. - -.. note:: - - This page covers attestation concepts and a local connectivity test only. - Deploying a production attestation service is out of scope for this documentation: the workflow is not NVIDIA-specific and is owned by the upstream Confidential Containers project. - For production attestation deployment, refer to the upstream `Confidential Containers documentation `__ and the end-to-end `NVIDIA NIM Confidential GPU Attestation `_ example. - -In Confidential Containers, a Trusted Execution Environment (TEE) isolates a workload from the host. -Attestation is a process that cryptographically proves the state of the guest TEE, including both the CPU and the GPU, to a remote verifier before any secret or sensitive resource is released to the workload. -Attestation is required for any feature that depends on secrets, including: - -* Pulling encrypted container images -* Accessing authenticated container registries -* Using sealed secrets -* Requesting secrets directly from workloads - -A complete attestation scenario covers not only the TEE but also the Kata Agent API surface: -which operations the untrusted host is allowed to request inside the guest. -An agent security policy constrains that surface. -Generate and attach that policy as part of the workload manifest so attestation of the guest -includes that constrained Agent API surface. -Refer to :ref:`Attach a Kata Agent Security Policy `. -The agent security policy is distinct from the Trustee policy that decides whether to release a KBS resource. - -Key Concepts -============ - -The following concepts appear throughout this page: - -* Confidential Containers (CoCo): The open-source project that implements the cloud-native approach to Confidential Computing. - CoCo uses Kata Containers as the sandbox and Trustee as the attestation framework. -* Trusted Execution Environment (TEE): A hardware-isolated environment, such as AMD SEV-SNP, Intel TDX, or an NVIDIA Confidential Computing GPU, that protects code and data in use. -* Remote attestation: The process of cryptographically proving to a remote party that a TEE is running the expected, untampered software stack before that party releases secrets to it. -* Trustee: The remote verifier in the Confidential Containers attestation flow. Trustee is composed of three cooperating services: - - * Key Broker Service (KBS): The HTTP endpoint that clients and confidential guests talk to. KBS orchestrates the attestation exchange and conditionally releases resources when policy allows. - * Attestation Service (AS): Verifies hardware evidence presented by a guest TEE against reference values. - * Reference Value Provider Service (RVPS): Holds the known-good reference values that the Attestation Service compares evidence against. -* KBS resource: A secret, for example, a key, credential, or token, that Trustee releases to a guest when attestation succeeds. Most resources are addressed by a three-part path: ``//``. -* Policy: The rule set that Trustee evaluates against verified evidence to decide whether to release a resource. By default, Trustee denies resource requests from clients that have not presented valid TEE evidence. - -Refer to the upstream `Confidential Containers documentation `__ for more details on these concepts and attestation best practices. - -Quickstart -========== - -This page walks you through standing up a development Trustee instance with Docker Compose, installing the Key Broker Service (KBS) client tool, and sending a sample resource request to confirm the system is reachable. -It runs on a standalone Linux host and does not require a Kubernetes cluster or the Confidential Containers runtime. - -The goal is to give you a working local attestation backend and a client to interact with it before you wire Trustee into a Confidential Containers workload. - -.. note:: - - This quickstart is for evaluation only. - Do not use the Trustee instance you stand up here in production. - This guide does not deploy a TEE, does not produce real hardware attestation evidence, and does not release any secrets to a workload. - It only validates that the Trustee components are running and reachable. - - A full end-to-end attestation workflow depends on your environment and your organization's security requirements. - For complete deployment guidance, refer to the upstream `Confidential Containers attestation documentation `_ and the `NVIDIA NIM Confidential GPU Attestation `_ example. - - -What You Will Build -------------------- - -By the end of this quickstart, you will have: - -* A local Trustee instance (KBS, Attestation Service, and Reference Value Provider Service) running in Docker containers on ``127.0.0.1:8080``. -* The ``kbs-client`` command-line tool installed and able to reach your Trustee instance. -* A sample resource request that exercises the end-to-end request path. - -You will know you are done when ``kbs-client`` can send a request to KBS and receive a response from the Trustee policy engine, even if that response is a policy denial. -A denial in this quickstart is the expected, successful outcome: it confirms that the client reached KBS, the Attestation Service evaluated the request, and policy was applied. - - -Prerequisites -------------- - -* A Linux host with internet access. - Trustee runs as a set of containers, so the host does not require confidential-computing hardware or an NVIDIA GPU. -* Docker Engine with the Compose plugin installed. - Refer to the `Docker Engine install guide `_ if Docker is not already installed. -* ``git``, ``curl``, and ``openssl`` available on the host. -* ORAS CLI installed and on your ``PATH``. - ORAS is used to pull the ``kbs-client`` binary from the upstream container registry. - Refer to the `ORAS installation guide `_ if ORAS is not already installed. - - -Step 1: Install Trustee with Docker Compose -------------------------------------------- - -Installing Trustee with Docker Compose is the recommended install path. -Clone the upstream Trustee repository at ${trustee_version}. -The repository ships with a ``docker-compose.yml`` that wires KBS, the Attestation Service, and the Reference Value Provider Service together. - -.. code-block:: console - - $ git clone --branch ${trustee_version} --depth 1 https://github.com/confidential-containers/trustee.git && cd trustee - -Start the Trustee containers in the background. - -.. code-block:: console - - $ docker compose up -d - -*Example Output:* - -.. code-block:: output - - [+] Running 4/4 - ✔ Network trustee_default Created - ✔ Container trustee-rvps-1 Started - ✔ Container trustee-as-1 Started - ✔ Container trustee-kbs-1 Started - -.. note:: - - On first run, ``docker compose up -d`` pulls the KBS, AS, and RVPS images before starting them. - This step can take several minutes. The command returns after the containers start. The services may need an additional few seconds to become ready to accept requests. - -.. note:: - - The Trustee ${trustee_version} `docker-compose.yml `_ still references ``:latest`` images for KBS, AS, and RVPS. - While cloning that tag pins the compose configuration to a released version, ``docker compose up -d`` still pulls whatever ``:latest`` resolves to at that time. - ``:latest`` does not match Trustee ${trustee_version}. - For a reproducible backend that matches this architecture, replace the three ``image:`` lines before you run ``docker compose up -d``: - - * KBS: ``ghcr.io/confidential-containers/staged-images/kbs-grpc-as:${trustee_image_tag}`` - * AS: ``ghcr.io/confidential-containers/staged-images/coco-as-grpc:${trustee_image_tag}`` - * RVPS: ``ghcr.io/confidential-containers/staged-images/rvps:${trustee_image_tag}`` - - Those tags are the Trustee ${trustee_version} commit, the same commit as the ``kbs-client`` artifact in the next step. - The GHCR registry does not publish a ``${trustee_version}`` tag for these images. - Equivalent digest pins are ``kbs-grpc-as@${trustee_kbs_image_digest}``, ``coco-as-grpc@${trustee_as_image_digest}``, and ``rvps@${trustee_rvps_image_digest}``. - This edit is unnecessary after Trustee starts pinning images in the release compose file. - -For details on optional configuration such as the admin keypair, debug logging, and per-service config files, refer to the upstream `Install Trustee in Docker `_ guide. - - -Step 2: Verify Trustee Is Running ---------------------------------- - -Confirm all three Trustee containers are up. - -.. code-block:: console - - $ docker compose ps - -*Example Output:* - -.. code-block:: output - - NAME IMAGE STATUS PORTS - trustee-as-1 .../attestation-service Up - - trustee-kbs-1 .../kbs Up 0.0.0.0:8080->8080/tcp - trustee-rvps-1 .../rvps Up - - -Confirm KBS is listening on port ``8080`` by sending a POST to the attestation endpoint. -The request body is intentionally empty. You are checking reachability, not submitting evidence. - -.. code-block:: console - - $ curl -X POST http://127.0.0.1:8080/kbs/v0/attest - -Any HTTP response from KBS, including an error response that rejects the empty request body, confirms KBS is listening and responding. -A connection refused or no-route error indicates that the containers are not running or that port ``8080`` is not exposed. - -.. note:: - - It is typically not recommended to curl the KBS endpoints directly unless you are checking connectivity. - Use the ``kbs-client``, installed in the next step, instead. - - -Step 3: Install the KBS Client Tool ------------------------------------ - -The KBS client tool, ``kbs-client``, is distributed as a container artifact in the Confidential Containers GitHub Container Registry. -This tool is mainly used for configuring Trustee. -The registry does not publish a ``${trustee_version}`` tag for this artifact. -Pull the ``sample_only`` build for the Trustee ${trustee_version} commit on ``x86_64``. - -.. code-block:: console - - $ oras pull ghcr.io/confidential-containers/staged-images/kbs-client:${kbs_client_tag} - -*Example Output:* - -.. code-block:: output - - Downloading 5148271f5a55 kbs-client - Downloaded 5148271f5a55 kbs-client - Pulled [registry] ghcr.io/confidential-containers/staged-images/kbs-client:${kbs_client_tag} - Digest: sha256:429be62c527e766a9854f9dac37f878010069c4aa6745d3d555d2bf393b9e82e - -Confirm the ``kbs-client`` binary was extracted to the current directory. - -.. code-block:: console - - $ ls kbs-client - -Make the binary executable. - -.. code-block:: console - - $ chmod +x kbs-client - -Confirm the binary runs. - -.. code-block:: console - - $ ./kbs-client --help - -.. note:: - - The ORAS-distributed ``kbs-client`` does not support requesting resources from inside a TEE enclave. - For in-enclave use, refer to the upstream `Client Tool documentation `_. - - -Step 4: Send a Sample Resource Request --------------------------------------- - -Use ``kbs-client`` to request a resource from your local Trustee. -The request below uses a placeholder resource path. -You do not need to pre-create the resource for this check. -The ``get-resource`` endpoint can be used (including inside a TEE), but it will always invoke the sample attester, which generates fake evidence for testing. - -.. code-block:: console - - $ ./kbs-client --url http://127.0.0.1:8080 get-resource --path my_repo/resource_type/123abc - -Trustee will deny the request because you are not running inside a TEE, required by the default policy, and you have not presented valid attestation evidence. -A policy-denied response is the expected, successful outcome of this quickstart. -It confirms that the client reached KBS, KBS routed the request through the Attestation Service, and the configured policy rejected the request. - -*Example Output:* - -.. code-block:: output - - WARN kbs_protocol::client::rcar_client: Authenticating with KBS failed. Perform a new RCAR handshake: ErrorInformation { - error_type: "https://github.com/confidential-containers/kbs/errors/PolicyDeny", - detail: "Access denied by policy", - } - Error: request unauthorized - -The ``PolicyDeny`` warning and the final ``request unauthorized`` error confirm that KBS received the request, the Attestation Service evaluated it, and policy rejected it. - -If you instead see a connection error, KBS is not reachable. Revisit Step 2. - - -Next Steps -========== - -You now have a working local Trustee instance and a client that can talk to it. For end-to-end deployment guidance, refer to the upstream Confidential Containers documentation: - -* `NVIDIA NIM Confidential GPU Attestation `_: A complete example deploying Trustee, configuring attestation policies, and running a confidential NVIDIA NIM workload with GPU attestation. -* `Attestation `_: Trustee architecture, configuration, resources, policies, the client tool, and guidance for production deployment topology, network configuration, and hardening. -* `Features `_: The complete set of Confidential Containers features, including how to wire attestation into real workloads. - -To shut down the local Trustee instance when you are finished, run the following command from the ``trustee`` repository directory: - -.. code-block:: console - - $ docker compose down diff --git a/confidential-containers/confidential-containers-deploy.rst b/confidential-containers/confidential-containers-deploy.rst deleted file mode 100644 index 89b65098b..000000000 --- a/confidential-containers/confidential-containers-deploy.rst +++ /dev/null @@ -1,490 +0,0 @@ -.. license-header - SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. - SPDX-License-Identifier: Apache-2.0 - - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - -.. headings # #, * *, =, -, ^, " - - -.. _confidential-containers-deploy: - -###################### -Detailed Install Guide -###################### - -As a :ref:`Kubernetes Cluster Administrator `, use these steps to deploy Kata Containers and the NVIDIA GPU Operator to your cluster and configure it for Confidential Containers. - -If you want the fastest path and intend to run Confidential Containers on every node in your cluster, use the :doc:`Quickstart Install ` instead. -Use this guide when you need per-node control, such as running Confidential Containers on some nodes and traditional GPU workloads on others, or when you want to use additional configuration options when installing the GPU Operator. - -.. _overview: - -**************** -Install Overview -**************** - -This guide assumes you completed :doc:`Prerequisites ` on an existing Kubernetes cluster with GPU worker nodes. - -Install workflow: - -#. :doc:`Prerequisites `: prepare worker hosts and cluster software. -#. :ref:`Label nodes to deploy Confidential Containers components `: select GPU workers for Confidential Containers workloads. -#. :ref:`Install Kata Containers `: install runtime classes and node-level Kata components. -#. :ref:`Install the NVIDIA GPU Operator `: deploy Confidential Containers operands on target nodes. - -**Success criteria:** Helm releases report ``STATUS: deployed``, the ``kata-deploy`` pod is ``Running``, SNP and TDX runtime classes are available, and all GPU Operator operands are healthy on target nodes. - -After completing the installation, you can :doc:`Run a Sample Workload ` to verify the deployment. - -.. _installation-and-configuration: - -.. _coco-label-nodes: - -************************************************** -Label Nodes for Confidential Containers Components -************************************************** - -The GPU Operator reads labels to determine what software components to deploy to a node. -To configure a node for Confidential Container workloads, you label the node with the ``nvidia.com/gpu.workload.config=vm-passthrough`` label. -Then, when the GPU Operator is installed in a subsequent step, it will deploy the software components needed to run Confidential Containers to the node. - -A node can only run one container runtime at a time, so a node configured for Confidential Container workloads cannot run traditional GPU container workloads. -The labeling approach is useful if you want to run Confidential Containers workloads on some nodes and traditional GPU container workloads on other nodes in your cluster. - -For more details on how the GPU Operator deploys components to your cluster, refer to the :ref:`GPU Operator Cluster Topology Considerations ` section in the architecture overview. - -.. tip:: - - Skip this section if you plan to use all nodes in your cluster to run Confidential Containers and instead set ``sandboxWorkloads.defaultWorkload=vm-passthrough`` when installing the GPU Operator. - -#. Get a list of the nodes in your cluster: - - .. code-block:: console - - $ kubectl get nodes - - *Example Output:* - - .. code-block:: output - - NAME STATUS ROLES AGE VERSION - node-01 Ready 10d v1.34.0 - node-02 Ready 10d v1.34.0 - - Identify the GPU worker node or nodes you want to configure for Confidential Containers and use its name in the next step. - -#. Set the ``NODE_NAME`` environment variable to the name of the node you want to configure: - - .. code-block:: console - - $ export NODE_NAME="" - - .. note:: - - Commands in this guide use the ``$NODE_NAME`` environment variable to reference this node. - -#. Label the node for Confidential Containers: - - .. code-block:: console - - $ kubectl label node $NODE_NAME nvidia.com/gpu.workload.config=vm-passthrough - - *Example Output:* - - .. code-block:: output - - node/ labeled - - If you see `` not labeled``, the label may already be set. - Continue to the next step to verify if the label was added. - - .. note:: - - To label multiple nodes at once, pass additional node names to the same command: - - .. code-block:: console - - $ kubectl label node nvidia.com/gpu.workload.config=vm-passthrough - -#. Verify all target nodes have the label by listing all nodes with the label: - - .. code-block:: console - - $ kubectl get nodes -l nvidia.com/gpu.workload.config=vm-passthrough - - *Example Output:* - - .. code-block:: output - - NAME STATUS ROLES AGE VERSION - node-01 Ready 10d v1.34.0 - -**Success criteria:** All nodes you intend to use for Confidential Container workloads appear in the output above. - -After all your desired nodes are labeled, you can continue to the next step to install Kata Containers. - - -.. _coco-install-kata-chart: - -************************************** -Install the Kata Containers Helm Chart -************************************** - -Install Kata Containers using the ``kata-deploy`` Helm chart. -The ``kata-deploy`` chart installs all required components from the Kata Containers project including the Kata Containers runtime binary, runtime configuration, UVM kernel, and images that NVIDIA uses for Confidential Containers and native Kata containers. - -The minimum required version is ${kata_version}. - -#. Set the chart version and registry path: - - .. code-block:: console - - $ export VERSION="${kata_version}" - $ export CHART="oci://ghcr.io/kata-containers/kata-deploy-charts/kata-deploy" - -#. Create a values file, such as ``kata-nvidia-gpu-values.yaml``, to configure the ``kata-deploy`` chart for NVIDIA Confidential Containers: - - .. literalinclude:: ./samples/kata-nvidia-gpu-values.yaml - :language: yaml - -#. Install the kata-deploy Helm chart with the values file: - - .. code-block:: console - - $ helm install kata-deploy "${CHART}" \ - --namespace kata-system --create-namespace \ - -f kata-nvidia-gpu-values.yaml \ - --wait --timeout 10m \ - --version "${VERSION}" - - *Example Output immediately after running the command:* - - .. code-block:: output - - Pulled: ghcr.io/kata-containers/kata-deploy-charts/kata-deploy:${kata_version} - Digest: sha256:aea41018779716ce2e0bf406d701637d10fb5a0792db51a08dfd3f76701eb933 - - The ``--wait`` flag in the install command instructs Helm to wait until the release is deployed before returning. - It can take a 2-3 minutes to return more output. - - *Example Output when the release is deployed:* - - .. code-block:: output - - Pulled: ghcr.io/kata-containers/kata-deploy-charts/kata-deploy:${kata_version} - Digest: sha256:aea41018779716ce2e0bf406d701637d10fb5a0792db51a08dfd3f76701eb933 - LAST DEPLOYED: Wed Apr 1 17:03:00 2026 - NAMESPACE: kata-system - STATUS: deployed - REVISION: 1 - DESCRIPTION: Install complete - TEST SUITE: None - - .. note:: - - There is a `known Helm issue `_ on single node clusters, that may result in the Helm command finishing before all deployed pods are finished initializing. - If you are deploying to a single node cluster, you may need to wait for an additional few minutes after the Helm command completes for the ``kata-deploy`` pod to be in the Running state. - - ``STATUS: deployed`` confirms the Helm release succeeded and the chart resources were applied. - The following steps confirm the Kata components are healthy. - - .. note:: - - Both ``kata-deploy`` and the GPU Operator can deploy Node Feature Discovery (NFD). - The values file disables the NFD deployment by ``kata-deploy``. - The GPU Operator will deploy and manage NFD in the next step. - -#. Verify that the ``kata-deploy`` pod is running: - - .. code-block:: console - - $ kubectl get pods -n kata-system | grep kata-deploy - - *Example Output:* - - .. code-block:: output - - kata-deploy-b2lzs 1/1 Running 0 6m37s - - A ``READY`` value of ``1/1`` and a ``STATUS`` of ``Running`` mean the ``kata-deploy`` pod installed the Kata components on the node successfully. - If the pod is ``Pending``, ``ContainerCreating``, or ``CrashLoopBackOff``, wait a minute and re-run the command. - If the ``kata-deploy`` pod does not reach ``Running``, refer to :ref:`View Kata Containers Logs ` in :doc:`Troubleshooting `. - -#. Verify that the ``kata-qemu-nvidia-gpu-snp`` and ``kata-qemu-nvidia-gpu-tdx`` runtime classes are available: - - .. code-block:: console - - $ kubectl get runtimeclass | grep kata-qemu-nvidia-gpu - - *Example Output:* - - .. code-block:: output - - NAME HANDLER AGE - kata-qemu-nvidia-gpu kata-qemu-nvidia-gpu 40s - kata-qemu-nvidia-gpu-snp kata-qemu-nvidia-gpu-snp 40s - kata-qemu-nvidia-gpu-tdx kata-qemu-nvidia-gpu-tdx 40s - - Several runtimes are installed by the ``kata-deploy`` chart. - The ``kata-qemu-nvidia-gpu`` runtime class is used with Kata - Containers, in a non-Confidential Containers scenario. - The ``kata-qemu-nvidia-gpu-snp`` for AMD-based systems or - ``kata-qemu-nvidia-gpu-tdx`` for Intel-based systems runtime - classes are used to deploy Confidential Containers workloads. - - The ``kata-deploy`` chart typically creates these runtime classes within 1-2 minutes after the ``kata-deploy`` pod reaches ``Running``. - If the SNP and TDX runtime classes are not listed immediately, the chart may still be initializing rather than failing. - Wait 1-2 minutes and re-run the command. - If they are still missing after the ``kata-deploy`` pod reports ``Running``, the install did not complete correctly. - Refer to :ref:`View Kata Containers Logs ` in :doc:`Troubleshooting ` for help diagnosing the issue. - On a single-node cluster, retry after a few minutes only if Helm returned before the ``kata-deploy`` pod reaches ``Running`` (refer to the note above). - Otherwise, refer to the log steps below. - -**Success criteria:** Helm reports ``STATUS: deployed``, the ``kata-deploy`` pod is ``Running``, and both ``kata-qemu-nvidia-gpu-snp`` and ``kata-qemu-nvidia-gpu-tdx`` are available on the cluster. -After all checks pass, continue to :ref:`Install the NVIDIA GPU Operator `. - -If the ``kata-deploy`` pod does not reach ``Running`` or the SNP and TDX runtime classes are missing, refer to :ref:`View Kata Containers Logs ` in :doc:`Troubleshooting `. - -.. _coco-install-gpu-operator: - -******************************* -Install the NVIDIA GPU Operator -******************************* - -Install the NVIDIA GPU Operator and configure it to deploy Confidential Container components. -For more details on each of the GPU Operator components, refer to the :ref:`GPU Operator Cluster Topology Considerations ` section in the architecture overview. - -#. Add and update the NVIDIA Helm repository: - - .. code-block:: console - - $ helm repo add nvidia https://helm.ngc.nvidia.com/nvidia \ - && helm repo update - - *Example Output:* - - .. code-block:: output - - "nvidia" has been added to your repositories - Hang tight while we grab the latest from your chart repositories... - ...Successfully got an update from the "nvidia" chart repository - Update Complete. ⎈Happy Helming!⎈ - -#. Install the GPU Operator with the following configuration: - - .. tip:: - - Add ``--set sandboxWorkloads.defaultWorkload=vm-passthrough`` to configure every worker node for Confidential Containers workloads. - Refer to the :ref:`Label Nodes for Confidential Containers Components ` section for more details on this use case. - - To customize the installation beyond the command below: - - * Refer to the :ref:`Common GPU Operator Configuration Settings ` section on this page for the Confidential Containers-specific configuration options you can specify when installing the GPU Operator. - - * Refer to the :ref:`Common chart customization options ` in :doc:`Installing the NVIDIA GPU Operator ` for the additional general configuration options you can specify when installing the GPU Operator. - - .. code-block:: console - - $ helm install --wait --timeout 10m --generate-name \ - -n gpu-operator --create-namespace \ - nvidia/gpu-operator \ - --set sandboxWorkloads.enabled=true \ - --set sandboxWorkloads.mode=kata \ - --set nfd.enabled=true \ - --set nfd.nodefeaturerules=true \ - --version=${gpu_operator_version} - - *Example Output:* - - .. code-block:: output - - NAME: gpu-operator - LAST DEPLOYED: Tue Mar 10 17:58:12 2026 - NAMESPACE: gpu-operator - STATUS: deployed - REVISION: 1 - TEST SUITE: None - - ``STATUS: deployed`` confirms the Helm release succeeded. - The ``--wait`` flag instructs Helm to wait until the release is deployed before returning. - It may take 3-5 minutes for the Helm command to complete. - - Use the following steps to confirm the GPU Operator components are deployed and configured correctly. - -#. Verify that all GPU Operator pods, especially the Confidential Computing Manager, Kata Device Plugin and VFIO Manager operands, are running: - - .. code-block:: console - - $ kubectl get pods -n gpu-operator - - *Example Output:* - - .. code-block:: output - - NAME READY STATUS RESTARTS AGE - gpu-operator-1766001809-node-feature-discovery-gc-75776475sxzkp 1/1 Running 0 86s - gpu-operator-1766001809-node-feature-discovery-master-6869lxq2g 1/1 Running 0 86s - gpu-operator-1766001809-node-feature-discovery-worker-mh4cv 1/1 Running 0 86s - gpu-operator-f48fd66b-vtfrl 1/1 Running 0 86s - nvidia-cc-manager-7z74t 1/1 Running 0 61s - nvidia-kata-sandbox-device-plugin-daemonset-d5rvg 1/1 Running 0 30s - nvidia-sandbox-validator-6xnzc 1/1 Running 0 30s - nvidia-vfio-manager-h229x 1/1 Running 0 62s - - Each pod should report a ``READY`` value of ``1/1`` and a ``STATUS`` of ``Running`` or ``Completed``. - The ``nvidia-cc-manager``, ``nvidia-kata-sandbox-device-plugin-daemonset``, and ``nvidia-vfio-manager`` operands are specific to Confidential Containers and must be present on labeled nodes. - Pods may briefly show ``Pending`` or ``Init`` while they start, which is expected. - When all operands are ``Running`` or ``Completed``, the GPU Operator components are deployed. - -#. If you have host access to the worker node, you can perform the following validation step to confirm that the host uses the vfio-pci device driver for GPUs: - - .. code-block:: console - - $ lspci -nnk -d 10de: - - *Example Output:* - - .. code-block:: output - - 65:00.0 3D controller [0302]: NVIDIA Corporation xxxxxxx [xxx] [10de:xxxx] (rev xx) - Subsystem: NVIDIA Corporation xxxxxxx [xxx] [10de:xxxx] - Kernel driver in use: vfio-pci - Kernel modules: nvidiafb, nouveau - - The ``Kernel driver in use: vfio-pci`` line in the output confirms the GPU is bound for VFIO passthrough into the confidential virtual machine. - If the driver in use is ``nvidia`` or ``nouveau`` instead, the GPU is not ready for passthrough. - Confirm your node meets the :ref:`Prerequisites ` section, including removing any NVIDIA GPU drivers on the host. - -**Success criteria:** All GPU Operator pods are ``Running`` or ``Completed``. -Your cluster is now configured to deploy workloads in Kata Containers. -Continue to :doc:`Run a Sample Workload ` to confirm everything is working as expected. - -If you are not seeing the expected output, view the logs for the GPU Operator pods or refer to :doc:`Troubleshooting `. - -.. _coco-configuration-settings: - -****************************************** -Common GPU Operator Configuration Settings -****************************************** - -The following are the available GPU Operator configuration settings to enable Confidential Containers: - -.. list-table:: - :widths: 20 50 30 - :header-rows: 1 - - * - Parameter - - Description - - Default - - * - ``sandboxWorkloads.enabled`` - - Enables sandbox workload management in the GPU Operator for virtual - machine-style workloads and related operands. - - ``false`` - - * - ``sandboxWorkloads.defaultWorkload`` - - Specifies the default type of workload for the cluster, one of ``container``, ``vm-passthrough``, or ``vm-vgpu``. - - Set to ``vm-passthrough`` if you plan to run all or mostly virtual machines in your cluster. - - ``container`` - - * - ``sandboxWorkloads.mode`` - - Specifies the sandbox mode to use when deploying sandbox workloads. - Accepted values are ``kubevirt`` (default) and ``kata``. - Set to ``kata`` to run Confidential Containers workloads in Kata Containers. - - ``kubevirt`` - - * - ``kataSandboxDevicePlugin.env`` - - Optional list of environment variables passed to the NVIDIA Kata - Device Plugin pod. Each list item is an ``EnvVar`` object with required - ``name`` and optional ``value`` fields. - Use the setting to configure ``P_GPU_ALIAS`` or ``NVSWITCH_ALIAS`` for the Kata sandbox device plugin. - Refer to the :ref:`Configuring GPU or NVSwitch Resource Types Name ` section for more details. - - ``[]`` (empty list) - -.. _coco-configuration-heterogeneous-clusters: - -*********************************************** -Configuring GPU or NVSwitch Resource Types Name -*********************************************** - -By default, the NVIDIA GPU Operator creates a resource type for GPUs and NVSwitches, ``nvidia.com/pgpu`` and ``nvidia.com/nvswitch``. -You can reference this name in your manifests to request GPU or NVSwitch resources for your workload. -If you want to use a different name, you can set the ``P_GPU_ALIAS`` or ``NVSWITCH_ALIAS`` environment variables in the Kata device plugin to your preferred name. -In clusters where all GPUs are the same model, a single resource type is typically sufficient. - -In heterogeneous clusters, where you have different GPU types on your nodes, you might want to use specific GPU types for your workload. -To do this, specify an empty ``P_GPU_ALIAS`` environment variable in the Kata sandbox device plugin by adding the following to your GPU Operator installation: -``--set kataSandboxDevicePlugin.env[0].name=P_GPU_ALIAS`` and -``--set kataSandboxDevicePlugin.env[0].value=""``. - -When this variable is set to ``""``, the Kata device plugin creates GPU model-specific resource types, for example ``nvidia.com/GH100_H200_141GB``, instead of the default ``nvidia.com/pgpu`` type. -Use the exposed device resource types in pod specs by specifying respective resource limits. - -Similarly, you can set ``NVSWITCH_ALIAS`` to ``""`` to advertise model-specific NVSwitch resource types. - -The following example installs the GPU Operator with both ``P_GPU_ALIAS`` and ``NVSWITCH_ALIAS`` configured: - -.. code-block:: console - - $ helm install --wait --timeout 10m --generate-name \ - -n gpu-operator --create-namespace \ - nvidia/gpu-operator \ - --set sandboxWorkloads.enabled=true \ - --set sandboxWorkloads.mode=kata \ - --set nfd.enabled=true \ - --set nfd.nodefeaturerules=true \ - --set kataSandboxDevicePlugin.env[0].name=P_GPU_ALIAS \ - --set kataSandboxDevicePlugin.env[0].value="" \ - --set kataSandboxDevicePlugin.env[1].name=NVSWITCH_ALIAS \ - --set kataSandboxDevicePlugin.env[1].value="" \ - --version=${gpu_operator_version} - -After installing the GPU Operator, you can view the GPU or NVSwitch resource types available on a node by running the following command: - -.. code-block:: console - - $ kubectl get node $NODE_NAME -o json | grep nvidia.com - -.. note:: - - The ``NODE_NAME`` environment variable was set in the :ref:`Label Nodes ` section. - If you want to view the resource types for a different node, you can update the ``NODE_NAME`` environment variable and run the command again. - -*Example Output:* - -.. code-block:: output - - "nvidia.com/GH100_H200_141GB": "1" - -You should see the resource type information for the GPUs and NVSwitches on the node. - - -********** -Next Steps -********** - -.. note:: - - You now have a working Confidential Containers runtime. - - Attestation is what cryptographically verifies the TEE and releases secrets to a - production workload. For attestation concepts and a local - connectivity test, see the :doc:`Attestation ` quickstart. For production attestation - deployment, refer to the upstream `Confidential Containers NVIDIA attestation guide - `__. - -* :doc:`Run a Sample Workload ` to verify your deployment. -* To help manage the lifecycle of Kata Containers, install the `Kata Lifecycle Manager `_. - This Argo Workflows-based tool manages Kata Containers upgrades and day-two operations. diff --git a/confidential-containers/configure-cc-mode.rst b/confidential-containers/configure-cc-mode.rst deleted file mode 100644 index d1e512bdf..000000000 --- a/confidential-containers/configure-cc-mode.rst +++ /dev/null @@ -1,220 +0,0 @@ -.. license-header - SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. - SPDX-License-Identifier: Apache-2.0 - - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - -.. headings # #, * *, =, -, ^, " - - -.. _managing-confidential-computing-mode: - -######################################### -Managing the Confidential Computing Mode -######################################### - -As a :ref:`Kubernetes Cluster Administrator `, use this page to configure the confidential computing mode of NVIDIA GPUs in your cluster. - -After installing the NVIDIA GPU Operator, you can use the GPU Operator to configure the confidential computing mode of the NVIDIA GPUs in your cluster. -You can set a cluster-wide default Confidential Computing mode, and you can set the mode on individual nodes. - -.. note:: - - Enabling Confidential Computing mode configures the GPU hardware boundary. - It does not by itself cryptographically verify the confidential environment or release secrets to a workload. - Confidentiality is established by attestation. - Refer to :doc:`Attestation `. - -Set the cluster-wide default mode using the ``ccManager.defaultMode=`` option. -The default value of ``ccManager.defaultMode`` is ``on``. -Set a node-level mode by applying the ``nvidia.com/cc.mode=`` label on the node. -If you set a specific mode on a node, it has higher precedence than the cluster-wide default mode. - -The supported modes are: - -.. list-table:: - :widths: 15 55 30 - :header-rows: 1 - - * - Mode - - Description - - Configuration Method - * - ``on`` (default) - - Enable Confidential Computing. - - cluster-wide default, node-level override - * - ``off`` - - Disable Confidential Computing. - - cluster-wide default, node-level override - * - ``ppcie`` - - Enable Confidential Computing on NVIDIA Hopper GPUs. - On the NVIDIA Hopper architecture, :ref:`multi-GPU passthrough ` - uses protected PCIe (PPCIE), which claims exclusive use of the NVSwitches for a single - Confidential Container virtual machine. - If you use NVIDIA Hopper GPUs for multi-GPU passthrough, set the mode to ``ppcie``. - The NVIDIA Blackwell architecture uses NVLink encryption, which places the switches outside - of the Trusted Computing Base (TCB), so ``ppcie`` mode is not required. - Use ``on`` mode for Blackwell. - - node-level override - -When you change the mode, the manager performs the following actions: - -* Evicts the other GPU Operator operands from the node. - However, the manager does not drain user workloads. You must make sure that no user workloads are running on the node before you change the mode. -* Changes the mode and resets the GPU. -* Reschedules the other GPU Operator operands. - -*********************************** -Setting a Cluster-Wide Default Mode -*********************************** - -.. note:: - - Before changing the mode, make sure that no user workloads are running on the node. - -To set a cluster-wide mode, specify the ``ccManager.defaultMode`` field like the following example: - -.. code-block:: console - - $ kubectl patch clusterpolicies.nvidia.com/cluster-policy \ - --type=merge \ - -p '{"spec": {"ccManager": {"defaultMode": "on"}}}' - -*Example Output:* - -.. code-block:: output - - clusterpolicy.nvidia.com/cluster-policy patched - -.. note:: - - The ``ppcie`` mode cannot be set as a cluster-wide default, it can only be set as a node label value. - -************************* -Setting a Node-Level Mode -************************* - -To set a node-level mode, apply the ``nvidia.com/cc.mode=`` label on the node. - -Set the ``NODE_NAME`` environment variable to the name of the node you want to configure: - -.. code-block:: console - - $ export NODE_NAME="" - -Then apply the label: - -.. code-block:: console - - $ kubectl label node $NODE_NAME nvidia.com/cc.mode=on --overwrite - -*Example Output:* - -.. code-block:: output - - node/ labeled - -For NVIDIA Hopper GPUs used in :ref:`multi-GPU passthrough `, set ``ppcie`` instead of ``on``: - -.. code-block:: console - - $ kubectl label node $NODE_NAME nvidia.com/cc.mode=ppcie --overwrite - -The mode that you set on a node has higher precedence than the cluster-wide default mode. - -*********************** -Verifying a Mode Change -*********************** - -To verify that a mode change was successful, view the ``nvidia.com/cc.mode``, -``nvidia.com/cc.mode.state``, and ``nvidia.com/cc.ready.state`` node labels: - -.. code-block:: console - - $ kubectl get node $NODE_NAME -o json | \ - jq '.metadata.labels | with_entries(select(.key | startswith("nvidia.com/cc")))' - -*Example Output (CC mode disabled):* - -.. code-block:: json - - { - "nvidia.com/cc.mode": "off", - "nvidia.com/cc.mode.state": "off", - "nvidia.com/cc.ready.state": "false" - } - -*Example Output (CC mode enabled):* - -.. code-block:: json - - { - "nvidia.com/cc.mode": "on", - "nvidia.com/cc.mode.state": "on", - "nvidia.com/cc.ready.state": "true" - } - -To wait for an enable transition (``on`` or ``ppcie``) to finish instead of polling the labels by hand, block until the node reports ready: - -.. code-block:: console - - $ until [ "$(kubectl get node $NODE_NAME -o jsonpath='{.metadata.labels.nvidia\.com/cc\.ready\.state}')" = "true" ]; do echo "waiting for CC mode to converge..."; sleep 5; done; echo "Node $NODE_NAME is ready for Confidential Containers" - -*Example Output:* - -.. code-block:: output - - waiting for CC mode to converge... - waiting for CC mode to converge... - Node is ready for Confidential Containers - -The loop exits when ``nvidia.com/cc.ready.state`` becomes ``true``, which the Confidential Computing Manager sets after the mode transition completes for ``on`` or ``ppcie``. - -When you disable CC mode after enabling it, wait one to two minutes for -``nvidia.com/cc.mode.state`` and ``nvidia.com/cc.ready.state`` to match the desired ``off`` state. -A mode change is complete and successful when ``nvidia.com/cc.mode`` and -``nvidia.com/cc.mode.state`` have the same value. - -If ``nvidia.com/cc.mode.state`` does not match ``nvidia.com/cc.mode``, refer to :ref:`nvidia.com/cc.mode.state Not Matching nvidia.com/cc.mode ` in the troubleshooting guide. -If ``nvidia.com/cc.mode.state`` is ``failed``, refer to :ref:`nvidia.com/cc.mode.state is failed `. - -************************************************ -Understanding Confidential Computing Mode Labels -************************************************ - -The following labels are used to manage the Confidential Computing mode on a node. -You only need to update the ``nvidia.com/cc.mode`` label, the other labels are managed by the Confidential Computing Manager to represent the current state of the Confidential Computing mode on the node. - -.. list-table:: - :widths: 30 20 50 - :header-rows: 1 - - * - Label Name - - Label Values - - Details - * - ``nvidia.com/cc.mode`` - - ``on``, ``off``, ``ppcie`` - - The desired Confidential Computing mode. - You update this node label to trigger a mode change. - * - ``nvidia.com/cc.mode.state`` - - ``on``, ``off``, ``ppcie``, ``failed`` - - Reflects the mode that was last successfully applied to the GPU hardware by the Confidential Computing Manager. - Its value mirrors the applied mode after the transition is complete on the node. - A value of ``failed`` indicates that the last mode transition encountered an error. - * - ``nvidia.com/cc.ready.state`` - - ``true``, ``false`` - - Indicates whether the node is ready to run Confidential Container workloads. - Set to ``true`` when ``cc.mode.state`` is ``on`` or ``ppcie``, and ``false`` when ``cc.mode.state`` is ``off``. - -.. note:: - - The ``ppcie`` mode is only supported on NVIDIA Hopper GPUs. diff --git a/confidential-containers/configure-workloads.rst b/confidential-containers/configure-workloads.rst deleted file mode 100644 index 25980dcc7..000000000 --- a/confidential-containers/configure-workloads.rst +++ /dev/null @@ -1,382 +0,0 @@ -.. license-header - SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. - SPDX-License-Identifier: Apache-2.0 - - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - -.. headings # #, * *, =, -, ^, " - - -.. _coco-configure-workloads: - -############################################ -Configuring Confidential Container Workloads -############################################ - -As a :ref:`Container User `, use this page to configure confidential GPU workloads on a prepared cluster. - -A Confidential Container workload is a standard Kubernetes pod that runs inside a TEE-protected -virtual machine and requests one or more GPUs through the NVIDIA Kata sandbox device plugin. -Compared with a traditional GPU pod, a Confidential Container workload pod manifest differs in -various ways. In particular, the pod manifest: - -* Selects a TEE-aware Kata runtime class instead of the default ``runc``-based runtime. -* Requests GPU and NVSwitch resources using the resource types advertised by the NVIDIA - Kata sandbox device plugin, which can be either default names or model-specific names. -* For NVSwitch-based HGX systems, requests every GPU and NVSwitch on the node together so - that all devices reside inside the same Confidential Container virtual machine. -* For an attested production deployment, includes a Kata agent security policy that limits - which Agent API calls the untrusted host can make into the guest. - -**Before this page:** Complete the :doc:`Detailed Install Guide ` and verify the cluster with :doc:`Run a Sample Workload ` (``Test PASSED`` in pod logs). -For install steps, refer to :doc:`Prerequisites ` and :doc:`Detailed Install Guide `. - -This page describes each of these decisions and provides single-GPU and multi-GPU passthrough -manifest examples that you can copy and adapt to your environment. -The install sample uses a minimal manifest and does not attach an agent security policy. - -******************************** -Select a Container Runtime Class -******************************** - -A Confidential Container workload must set ``spec.runtimeClassName`` to a TEE-aware Kata -runtime that NVIDIA provides through the ``kata-deploy`` Helm chart. -Select the runtime class based on the CPU TEE on the target worker node: - -.. list-table:: - :header-rows: 1 - :widths: 50 50 - - * - Node TEE - - Runtime class - * - AMD SEV-SNP - - ``kata-qemu-nvidia-gpu-snp`` - * - Intel TDX - - ``kata-qemu-nvidia-gpu-tdx`` - -The ``kata-deploy`` chart also installs a ``kata-qemu-nvidia-gpu`` runtime class. -That class is intended for non-confidential Kata workloads. - -.. _coco-resource-types: - -***************************************** -Reference GPU and NVSwitch Resource Types -***************************************** - -The NVIDIA Kata sandbox device plugin advertises GPUs and NVSwitches to Kubernetes as extended resources. -Your pod manifest requests those resources under ``resources.limits``. -You can use either the default resource types or model-specific resource types. - -By default, every passthrough GPU is advertised as ``nvidia.com/pgpu`` and every NVSwitch is advertised as ``nvidia.com/nvswitch``. -These names are stable across GPU models, which keeps manifests portable when every node in your cluster has the same GPU type. - -A sample resource request using the default resource type is shown below: - -.. code-block:: yaml - - resources: - limits: - nvidia.com/pgpu: "1" - -In heterogeneous clusters, where worker nodes use different GPU models, you can configure the Kata sandbox device plugin to advertise resources under model-specific names by setting -``P_GPU_ALIAS=""`` (and optionally ``NVSWITCH_ALIAS=""``) on the plugin. -With this configuration, GPUs are exposed as resources such as ``nvidia.com/GH100_H200_141GB``, -which lets a workload pin itself to a specific accelerator model. - -Refer to :ref:`Configuring GPU or NVSwitch Resource Types Name ` -for the GPU Operator install flags that enable this behavior. - -Use the model-specific resource name in workloads that must target a specific accelerator: - -.. code-block:: yaml - - resources: - limits: - nvidia.com/GH100_H200_141GB: "1" - - -Set the ``NODE_NAME`` environment variable to the node you want to check: - -.. code-block:: console - - $ export NODE_NAME="" - -To list the GPU and NVSwitch resource types advertised on a node, run: - -.. code-block:: console - - $ kubectl get node $NODE_NAME -o json | grep nvidia.com - -*Example Output:* - -.. code-block:: output - - "nvidia.com/GH100_H200_141GB": "1" - -.. _coco-single-gpu-workload: - -********************** -Single-GPU Passthrough -********************** - -A single-GPU workload requests one GPU and runs inside its own Confidential Container virtual -machine. -This pattern is the recommended starting point for verifying a deployment and for most -independent workloads that do not require NVLink between GPUs. - -#. Create a file, such as ``cuda-vectoradd-kata.yaml``: - - .. code-block:: yaml - :emphasize-lines: 7,14 - - apiVersion: v1 - kind: Pod - metadata: - name: cuda-vectoradd-kata - namespace: default - spec: - runtimeClassName: kata-qemu-nvidia-gpu-snp # or kata-qemu-nvidia-gpu-tdx - restartPolicy: Never - containers: - - name: cuda-vectoradd - image: "nvcr.io/nvidia/k8s/cuda-sample:vectoradd-cuda12.5.0-ubuntu22.04" - resources: - limits: - nvidia.com/pgpu: "1" - memory: 16Gi - - .. note:: - - If you configured the Kata sandbox device plugin to use model-specific resource types, - replace ``nvidia.com/pgpu`` with the appropriate model-specific name, such as - ``nvidia.com/GH100_H200_141GB``. - -#. Create the pod: - - .. code-block:: console - - $ kubectl apply -f cuda-vectoradd-kata.yaml - -#. Verify the workload completes successfully: - - .. code-block:: console - - $ kubectl logs cuda-vectoradd-kata - - *Example Output:* - - .. code-block:: output - - [Vector addition of 50000 elements] - Copy input data from the host memory to the CUDA device - CUDA kernel launch with 196 blocks of 256 threads - Copy output data from the CUDA device to the host memory - Test PASSED - Done - -Refer to :doc:`Run a Sample Workload ` for the end-to-end verification flow including -deletion and pending-pod guidance. - -.. _coco-multi-gpu-prereqs: -.. _coco-multi-gpu-passthrough: - -********************* -Multi-GPU Passthrough -********************* - -Multi-GPU passthrough assigns every GPU and NVSwitch on a node to a single Confidential -Container virtual machine. -This configuration is required for NVSwitch (NVLink) based HGX systems running confidential -workloads. - -.. important:: - - You must assign all the GPUs and NVSwitches on the node to the same Confidential Container - virtual machine. - Configuring only a subset of GPUs for Confidential Computing on a single node is not - supported. - -NVIDIA Hopper PPCIE Mode -======================== - -For NVIDIA Hopper GPUs, multi-GPU passthrough requires protected PCIe (PPCIE) mode, which -claims exclusive use of the NVSwitches for a single Confidential Container. -The NVIDIA Confidential Computing Manager for Kubernetes transitions GPUs into the correct -mode based on the ``cc.mode`` label that you set. - -#. Set the ``NODE_NAME`` environment variable to the node you want to configure: - - .. code-block:: console - - $ export NODE_NAME="" - -#. Apply the ``ppcie`` CC mode label to the node: - - .. code-block:: console - - $ kubectl label node $NODE_NAME nvidia.com/cc.mode=ppcie --overwrite - -Refer to :doc:`Managing the Confidential Computing Mode ` for full details -on setting the CC mode and verifying the change. - -NVIDIA Blackwell GPUs use NVLink encryption, which places the switches outside of the -Trusted Computing Base (TCB), so the default CC mode of ``on`` is sufficient and no additional -configuration is required. - -Run a Multi-GPU Workload -======================== - -#. Create a file, such as ``multi-gpu-kata.yaml``, with a pod manifest that requests every GPU - and NVSwitch on the node: - - .. code-block:: yaml - :emphasize-lines: 7,14-16 - - apiVersion: v1 - kind: Pod - metadata: - name: multi-gpu-kata - namespace: default - spec: - runtimeClassName: kata-qemu-nvidia-gpu-snp # or kata-qemu-nvidia-gpu-tdx - restartPolicy: Never - containers: - - name: cuda-sample - image: "nvcr.io/nvidia/k8s/cuda-sample:vectoradd-cuda12.5.0-ubuntu22.04" - resources: - limits: - nvidia.com/pgpu: "8" - nvidia.com/nvswitch: "4" # Only for NVIDIA Hopper GPUs with PPCIE mode - memory: 128Gi - - .. note:: - - If you configured ``P_GPU_ALIAS`` or ``NVSWITCH_ALIAS`` for heterogeneous clusters, - replace ``nvidia.com/pgpu`` and ``nvidia.com/nvswitch`` with the corresponding - model-specific resource types. - Refer to :ref:`Reference GPU and NVSwitch Resource Types ` - for details. - -#. Create the pod: - - .. code-block:: console - - $ kubectl apply -f multi-gpu-kata.yaml - - *Example Output:* - - .. code-block:: output - - pod/multi-gpu-kata created - -#. Verify the pod is running: - - .. code-block:: console - - $ kubectl get pod multi-gpu-kata - - *Example Output:* - - .. code-block:: output - - NAME READY STATUS RESTARTS AGE - multi-gpu-kata 1/1 Running 0 30s - -#. Verify that all GPUs are visible inside the container: - - .. code-block:: console - - $ kubectl exec multi-gpu-kata -- nvidia-smi -L - - *Example Output:* - - .. code-block:: output - - GPU 0: NVIDIA H100 (UUID: GPU-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) - GPU 1: NVIDIA H100 (UUID: GPU-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) - GPU 2: NVIDIA H100 (UUID: GPU-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) - GPU 3: NVIDIA H100 (UUID: GPU-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) - GPU 4: NVIDIA H100 (UUID: GPU-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) - GPU 5: NVIDIA H100 (UUID: GPU-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) - GPU 6: NVIDIA H100 (UUID: GPU-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) - GPU 7: NVIDIA H100 (UUID: GPU-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) - -#. Delete the pod: - - .. code-block:: console - - $ kubectl delete -f multi-gpu-kata.yaml - -.. _kata-agent-security-policy: - -*********************************** -Attach a Kata Agent Security Policy -*********************************** - -The Kata agent runs inside the guest virtual machine and manages the container lifecycle. -Because the Kata shim on the host is outside the TEE, the untrusted host can still issue Agent -API calls into the guest unless you restrict those Agent API calls. -An *agent security policy* is a Rego policy that the agent enforces so that only the operations -your workload declared are allowed. - -The :doc:`sample workload ` omits an agent policy so that you can confirm -GPU passthrough with the smallest possible manifest. -Do not treat that YAML as a production template. - -The Kata Containers ``genpolicy`` tool reads your Kubernetes YAML, infers the intended Agent API -calls, encodes the policy in base64, and appends it as an annotation on the same file. -The Kata agent in the guest receives that annotation. -Use ``genpolicy`` ${genpolicy_version}, which is the version this architecture validates with that agent. -Refer to :ref:`Supported Software Components ` for the component matrix. - -#. Download ``genpolicy`` ${genpolicy_version} from the - `Kata Containers ${genpolicy_version} release `_. - For usage details, refer to the - `Agent Policy generation tool `_ - documentation. - -#. Run ``genpolicy`` against the manifest to deploy: - - .. code-block:: console - - $ genpolicy -y cuda-vectoradd-kata.yaml - - Review the generated policy before you apply the manifest. - The automatically-generated policy is a starting point. - The policy can allow operations you do not want, such as ``kubectl exec``, or omit operations your - workload needs. - - .. important:: - - Review and, if needed, edit the policy so that it matches your threat model before you - use it. - -#. Apply the annotated manifest: - - .. code-block:: console - - $ kubectl apply -f cuda-vectoradd-kata.yaml - -********** -Next Steps -********** - -* Refer to :doc:`Attestation ` for Trustee concepts and a local connectivity test. - A complete attestation scenario must not only cover the TEE but also the Kata Agent API surface. - For this purpose, the agent security policy contained in the workload annotation is included in the measured - payload that is attested with the guest. - The agent security policy is distinct from the Trustee attestation policy that decides whether - to release secrets. - Refer to the upstream `Understanding CoCo Policies `__. -* Refer to :doc:`Managing the Confidential Computing Mode ` to change the CC mode on GPUs at the cluster or node level. -* Refer to :doc:`Troubleshooting ` if a workload does not schedule or the pod stays ``Pending``. diff --git a/confidential-containers/graphics/CoCo-Architecture.png b/confidential-containers/graphics/CoCo-Architecture.png deleted file mode 100644 index 1320c291f..000000000 Binary files a/confidential-containers/graphics/CoCo-Architecture.png and /dev/null differ diff --git a/confidential-containers/graphics/CoCo-Reference-Architecture-Dark.png b/confidential-containers/graphics/CoCo-Reference-Architecture-Dark.png deleted file mode 100644 index 26da1e093..000000000 Binary files a/confidential-containers/graphics/CoCo-Reference-Architecture-Dark.png and /dev/null differ diff --git a/confidential-containers/graphics/CoCo-Reference-Architecture.png b/confidential-containers/graphics/CoCo-Reference-Architecture.png deleted file mode 100644 index 9fcba1f68..000000000 Binary files a/confidential-containers/graphics/CoCo-Reference-Architecture.png and /dev/null differ diff --git a/confidential-containers/graphics/CoCo-Sample-Workflow.png b/confidential-containers/graphics/CoCo-Sample-Workflow.png deleted file mode 100644 index d6fc7c6f9..000000000 Binary files a/confidential-containers/graphics/CoCo-Sample-Workflow.png and /dev/null differ diff --git a/confidential-containers/index.rst b/confidential-containers/index.rst deleted file mode 100644 index 9427eea6e..000000000 --- a/confidential-containers/index.rst +++ /dev/null @@ -1,204 +0,0 @@ -.. license-header - SPDX-FileCopyrightText: Copyright (c) 2023 NVIDIA CORPORATION & AFFILIATES. All rights reserved. - SPDX-License-Identifier: Apache-2.0 - - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - -.. headings # #, * *, =, -, ^, " - -################################# -NVIDIA Confidential Containers -################################# - -.. toctree:: - :caption: Learn - :hidden: - :titlesonly: - - Overview - Reference Architecture - Personas - Supported Platforms - -.. toctree:: - :caption: Install - :hidden: - :titlesonly: - - Prerequisites - Quickstart Install - Detailed Install Guide - Run a Sample Workload - -.. toctree:: - :caption: Configuration - :hidden: - :titlesonly: - - Configuring Workloads - Managing the Confidential Computing Mode - Attestation - -.. toctree:: - :caption: Reference - :hidden: - :titlesonly: - - Troubleshooting - Release Notes - Licensing - -NVIDIA Confidential Containers is a validated reference architecture for running GPU-accelerated AI workloads on Kubernetes inside hardware-enforced Trusted Execution Environments (TEEs). -It extends NVIDIA GPU Confidential Computing to standard Kubernetes deployments using CNCF `Confidential Containers `__ and Kata Containers with the NVIDIA GPU Operator. -Use it to protect model intellectual property and sensitive data from untrusted infrastructure across public cloud, on-premises, and edge deployments. - -Benefits -======== - -Confidential Containers provides the following benefits: - -* Protect model IP and sensitive data on untrusted public cloud, on-premises, or edge infrastructure. -* Deploy proprietary generative AI models in regulated industries on third-party or private clusters. -* Isolate GPU workloads in hardware-protected enclaves with encrypted memory and integrity verification. -* Operate confidential workloads with standard Kubernetes pods, runtime classes, and scheduling. -* Verify TEE state through remote attestation before releasing secrets or decrypted model weights. - -Refer to :doc:`Reference Architecture ` for background, use cases, and architecture diagrams. - -Use Cases ---------- - -Common scenarios include protecting proprietary model IP on third-party infrastructure, running frontier models in a sovereign environment, and processing sensitive enterprise data in data clean rooms. -Refer to :ref:`Use Cases ` in the Reference Architecture for workflows and deployment scenarios. - -Core Concepts -============= - -`Confidential Containers `__ runs Kubernetes pods in hardware-isolated virtual machines instead of on the shared host kernel, protecting workloads from the host and other tenants. -On supported hardware (AMD SEV-SNP or Intel TDX), that isolation forms a trusted execution environment (TEE) with encrypted memory and integrity verification. - -Attestation, sealed secrets, and encrypted container images are core to the model. -Refer to :ref:`Software Components for Confidential Containers ` in the Reference Architecture. - -Core Components -=============== - -This documentation focuses on the components you install, configure, and operate to run workloads in a Confidential Containers runtime on Kubernetes. -The :doc:`Reference Architecture ` describes the full stack. -The install guides cover Kata Containers and the NVIDIA GPU Operator end to end. - -* Kata Containers: Runs pods inside TEE-protected virtual machines instead of on the shared host kernel. - Install Kata Deploy and TEE-specific runtime shims in :doc:`Quickstart Install ` and :doc:`Detailed Install Guide `. - Schedule workloads with a TEE-aware ``RuntimeClass`` in :doc:`Configuring Workloads `. - -* NVIDIA GPU Operator: Automates GPU Confidential Computing on eligible nodes, including CC mode, VFIO passthrough, and GPU allocation for Kata pods. - Configure the Operator and node labels in :doc:`Detailed Install Guide `. - Manage CC mode in :doc:`Managing the Confidential Computing Mode `. - - For Confidential Containers, the Operator deploys: - - * NVIDIA Confidential Computing Manager (cc-manager) - * NVIDIA Kata Sandbox Device Plugin - * NVIDIA VFIO Manager - * Node Feature Discovery (NFD) - -Using This Documentation -======================== - -This documentation describes the NVIDIA reference architecture for Confidential Containers and deployment recommendations for the upstream `CNCF Confidential Containers project `_ with NVIDIA GPUs. -It covers NVIDIA-specific configurations needed to run Confidential Containers workloads on Kubernetes. -This primarily includes the steps to enable and configure Kata Containers and the NVIDIA GPU Operator on your cluster. - -For advanced Confidential Containers topics and day-two operations, refer to the upstream `Confidential Containers documentation `__, as the workflows and implementations are not NVIDIA specific. -For example, an attestation implementation is not specific to NVIDIA GPUs. -A brief attestation overview and evaluation quickstart is available in :doc:`Attestation `, but full production attestation implementation guides are in the upstream `Confidential Containers attestation documentation `__. - - -Learn -===== - -.. grid:: 2 - :gutter: 3 - - .. grid-item-card:: :octicon:`book;1.5em;sd-mr-1` Reference Architecture - :link: overview - :link-type: doc - - Use cases, software components, cluster topology, limitations, and security considerations. - - .. grid-item-card:: :octicon:`info;1.5em;sd-mr-1` Personas - :link: personas - :link-type: doc - - Roles, responsibilities, and documentation navigation by persona. - - - .. grid-item-card:: :octicon:`server;1.5em;sd-mr-1` Supported Platforms and Software Components - :link: supported-platforms - :link-type: doc - - Validated hardware, OS, and component versions. - -Install -======= - -.. grid:: 2 - :gutter: 3 - - .. grid-item-card:: :octicon:`checklist;1.5em;sd-mr-1` Prerequisites - :link: prerequisites - :link-type: doc - - Hardware, BIOS, and Kubernetes cluster requirements. - - .. grid-item-card:: :octicon:`zap;1.5em;sd-mr-1` Quickstart Install - :link: install-quickstart - :link-type: doc - - Minimal steps to install Kata Containers and the GPU Operator. - - .. grid-item-card:: :octicon:`rocket;1.5em;sd-mr-1` Detailed Install Guide - :link: confidential-containers-deploy - :link-type: doc - - Install with per-node labeling, configuration options, and troubleshooting. - - .. grid-item-card:: :octicon:`play;1.5em;sd-mr-1` Run a Sample Workload - :link: run-sample-workload - :link-type: doc - - Run a sample GPU workload; success is ``Test PASSED`` in the pod logs. - -Configuration -============= - -.. grid:: 2 - :gutter: 3 - - .. grid-item-card:: :octicon:`cpu;1.5em;sd-mr-1` Configuring Workloads - :link: configure-workloads - :link-type: doc - - Runtime classes, resource types, multi-GPU passthrough, and agent security policy. - - .. grid-item-card:: :octicon:`gear;1.5em;sd-mr-1` Managing the Confidential Computing Mode - :link: configure-cc-mode - :link-type: doc - - Set CC mode at the cluster or node level. - - .. grid-item-card:: :octicon:`shield-check;1.5em;sd-mr-1` Attestation - :link: attestation - :link-type: doc - - Attestation concepts and a Trustee quickstart for connectivity testing. diff --git a/confidential-containers/install-quickstart.rst b/confidential-containers/install-quickstart.rst deleted file mode 100644 index cc7d01574..000000000 --- a/confidential-containers/install-quickstart.rst +++ /dev/null @@ -1,219 +0,0 @@ -.. license-header - SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. - SPDX-License-Identifier: Apache-2.0 - - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - -.. headings # #, * *, =, -, ^, " - - -.. _coco-install-quickstart: - -################## -Quickstart Install -################## - -As a :ref:`Kubernetes Cluster Administrator `, use these steps to install Kata Containers and the NVIDIA GPU Operator with minimal steps. -For additional configuration options and install details, refer to the :doc:`Detailed Install Guide `. - -This quickstart will configure every node in your cluster for Confidential Containers workloads. -This is ideal for evaluation or dedicated Confidential Containers clusters. -If you need to run Confidential Containers on only some nodes while keeping traditional GPU workloads on others, or you want more control over the installation, use the :ref:`Label Nodes for Confidential Containers Components ` section in the :doc:`Detailed Install Guide `. - -This quickstart takes approximately 10 minutes to complete. - -.. note:: - - Before starting, make sure your cluster meets the :doc:`Prerequisites `. - -What You Will Build -------------------- - -By the end of this quickstart, you will have: - -* Kata Containers running on your cluster. -* The NVIDIA GPU Operator installed and configured for Confidential Containers. -* All cluster nodes configured for Confidential Containers workloads. - -.. _quickstart-install-kata: - -************************************** -Install the Kata Containers Helm Chart -************************************** - -#. Set the chart version and registry path: - - .. code-block:: console - - $ export VERSION="${kata_version}" - $ export CHART="oci://ghcr.io/kata-containers/kata-deploy-charts/kata-deploy" - -#. Create a values file, such as ``kata-nvidia-gpu-values.yaml``, to configure the ``kata-deploy`` chart for NVIDIA Confidential Containers: - - .. literalinclude:: ./samples/kata-nvidia-gpu-values.yaml - :language: yaml - -#. Install the ``kata-deploy`` Helm chart with the values file: - - .. code-block:: console - - $ helm install kata-deploy "${CHART}" \ - --namespace kata-system --create-namespace \ - -f kata-nvidia-gpu-values.yaml \ - --wait --timeout 10m \ - --version "${VERSION}" - - *Example Output:* - - .. code-block:: output - - Pulled: ghcr.io/kata-containers/kata-deploy-charts/kata-deploy:${kata_version} - Digest: sha256:aea41018779716ce2e0bf406d701637d10fb5a0792db51a08dfd3f76701eb933 - LAST DEPLOYED: Wed Apr 1 17:03:00 2026 - NAMESPACE: kata-system - STATUS: deployed - REVISION: 1 - DESCRIPTION: Install complete - TEST SUITE: None - - It can take 2 to 3 minutes for the command to return and all output to be printed. - - .. note:: - - There is a `known Helm issue `_ on single-node clusters that may result in the Helm command finishing before all pods are done initializing. - If you are deploying to a single-node cluster, wait a few additional minutes after the command completes. - -#. Verify that the ``kata-deploy`` pod is running: - - .. code-block:: console - - $ kubectl get pods -n kata-system | grep kata-deploy - - *Example Output:* - - .. code-block:: output - - kata-deploy-b2lzs 1/1 Running 0 6m37s - - A ``READY`` value of ``1/1`` and a ``STATUS`` of ``Running`` mean the ``kata-deploy`` pod installed the Kata components on the node. - If the pod does not reach ``Running``, refer to :ref:`View Kata Containers Logs ` in :doc:`Troubleshooting `. - -#. Verify the ``kata-qemu-nvidia-gpu-snp`` and ``kata-qemu-nvidia-gpu-tdx`` runtime classes are available: - - After ``helm install`` completes, the ``kata-deploy`` chart creates the Kata ``RuntimeClass`` resources on the cluster. - This usually happens within 1-2 minutes after the ``kata-deploy`` pod reaches ``Running``. - Confirm SNP and TDX classes are present before you continue to :ref:`Install the NVIDIA GPU Operator `. - - .. code-block:: console - - $ kubectl get runtimeclass | grep kata-qemu-nvidia-gpu - - *Example Output:* - - .. code-block:: output - - NAME HANDLER AGE - kata-qemu-nvidia-gpu kata-qemu-nvidia-gpu 40s - kata-qemu-nvidia-gpu-snp kata-qemu-nvidia-gpu-snp 40s - kata-qemu-nvidia-gpu-tdx kata-qemu-nvidia-gpu-tdx 40s - - If the SNP and TDX runtime classes are not listed immediately, the chart may still be initializing rather than failing. - Wait 1-2 minutes and re-run the command. - If they are still missing after the ``kata-deploy`` pod reports ``Running``, the install did not complete correctly. - On a single-node cluster, retry after a few minutes only if Helm returned before the ``kata-deploy`` pod reaches ``Running`` (refer to the note above). - Otherwise, refer to :doc:`Troubleshooting `. - -**Success criteria:** Helm reports ``STATUS: deployed`` and both SNP and TDX runtime classes appear in the output above. - -.. _quickstart-install-gpu-operator: - -******************************* -Install the NVIDIA GPU Operator -******************************* - -#. Add and update the NVIDIA Helm repository: - - .. code-block:: console - - $ helm repo add nvidia https://helm.ngc.nvidia.com/nvidia \ - && helm repo update - - *Example Output:* - - .. code-block:: output - - "nvidia" has been added to your repositories - Hang tight while we grab the latest from your chart repositories... - ...Successfully got an update from the "nvidia" chart repository - Update Complete. ⎈Happy Helming!⎈ - -#. Install the GPU Operator configured for Confidential Containers on all nodes: - - .. code-block:: console - - $ helm install --wait --timeout 10m --generate-name \ - -n gpu-operator --create-namespace \ - nvidia/gpu-operator \ - --set sandboxWorkloads.enabled=true \ - --set sandboxWorkloads.defaultWorkload=vm-passthrough \ - --set sandboxWorkloads.mode=kata \ - --set nfd.enabled=true \ - --set nfd.nodefeaturerules=true \ - --version=${gpu_operator_version} - - *Example Output:* - - .. code-block:: output - - NAME: gpu-operator - LAST DEPLOYED: Tue Mar 10 17:58:12 2026 - NAMESPACE: gpu-operator - STATUS: deployed - REVISION: 1 - TEST SUITE: None - - It may take 3 to 5 minutes for the Helm release to complete and for all GPU Operator pods to reach the Running state. - - The ``sandboxWorkloads.defaultWorkload=vm-passthrough`` flag in the Helm install command sets the default cluster workload type for Confidential Containers. - -#. Verify that all GPU Operator pods are running: - - .. code-block:: console - - $ kubectl get pods -n gpu-operator - - *Example Output:* - - .. code-block:: output - - NAME READY STATUS RESTARTS AGE - gpu-operator-1766001809-node-feature-discovery-gc-75776475sxzkp 1/1 Running 0 86s - gpu-operator-1766001809-node-feature-discovery-master-6869lxq2g 1/1 Running 0 86s - gpu-operator-1766001809-node-feature-discovery-worker-mh4cv 1/1 Running 0 86s - gpu-operator-f48fd66b-vtfrl 1/1 Running 0 86s - nvidia-cc-manager-7z74t 1/1 Running 0 61s - nvidia-kata-sandbox-device-plugin-daemonset-d5rvg 1/1 Running 0 30s - nvidia-sandbox-validator-6xnzc 1/1 Running 0 30s - nvidia-vfio-manager-h229x 1/1 Running 0 62s - -**Success criteria:** All GPU Operator pods are ``Running`` or ``Completed``. - -Your cluster is now configured to deploy GPU workloads into the SNP and TDX runtime classes on all nodes. - -********** -Next Steps -********** - -* Continue to :doc:`Run a Sample Workload ` to confirm the deployment. - - diff --git a/confidential-containers/licensing.rst b/confidential-containers/licensing.rst deleted file mode 100644 index d30207776..000000000 --- a/confidential-containers/licensing.rst +++ /dev/null @@ -1,27 +0,0 @@ -.. license-header - SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. - SPDX-License-Identifier: Apache-2.0 - - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - -.. headings # #, * *, =, -, ^, " - -######### -Licensing -######### - -While the Confidential Containers (CoCo) Reference Architecture includes some components that are open source, the NVIDIA Confidential Computing capability is a licensed feature for production use cases. -To use these products, you must have a valid NVIDIA Confidential Computing license. -Refer to the `NVIDIA Product-Specific Terms for NVIDIA Confidential Computing `_ for more information. - - diff --git a/confidential-containers/llms.txt b/confidential-containers/llms.txt deleted file mode 100644 index a462d147f..000000000 --- a/confidential-containers/llms.txt +++ /dev/null @@ -1,45 +0,0 @@ -# NVIDIA Confidential Containers - -> A reference implementation, built from open-source components (Kubernetes, Kata -> Containers, QEMU/OVMF, NVIDIA GPU Operator, Node Feature Discovery, and Trustee -> for attestation), that extends CPU + GPU confidential computing to Kubernetes -> workloads. It protects data-in-use and model IP for regulated/enterprise AI by -> running GPU workloads inside hardware-based Trusted Execution Environments (TEEs: -> AMD SEV-SNP or Intel TDX) with GPU passthrough. - -Scope notes for agents and readers: -- This is a REFERENCE IMPLEMENTATION with example component choices, not a locked - spec or turnkey product. Trustee and the NVIDIA Remote Attestation Service are - EXAMPLE attestation implementations. -- The installation guide sets up CoCo on a node that ALREADY meets the stated - Prerequisites (hardware/TEE, host OS + kernel, Kubernetes, containerd, BIOS). It - is not a from-bare-metal tutorial and the attestation section shows primary setup, - not a complete end-to-end attestation workflow. -- Canonical source of truth: docs.nvidia.com. Upstream confidentialcontainers.org - and github.com/confidential-containers are referenced only for advanced/optional - detail. - -## Learn -- [Reference Architecture](https://docs.nvidia.com/datacenter/cloud-native/confidential-containers/latest/overview.html): What CoCo is, the trust boundary (TEE vs untrusted privileged infrastructure), the CPU+GPU-CC-to-Kubernetes value proposition, and limitations. -- [Personas](https://docs.nvidia.com/datacenter/cloud-native/confidential-containers/latest/personas.html): Target roles — hardware IT admin, host OS admin, Kubernetes cluster admin, security engineer, container user (plus application-owner and enterprise/compliance stakeholders). - -## Prerequisites & platforms -- [Supported Platforms and Software Components](https://docs.nvidia.com/datacenter/cloud-native/confidential-containers/latest/supported-platforms.html): Validated versions — OS/kernel, containerd, Kubernetes, Kata, GPU Operator — and supported CPUs (AMD Genoa/Milan, Intel ER/GR) and GPUs (H100/H200/B200/RTX Pro 6000, single- and multi-GPU PPCIe). -- [Prerequisites](https://docs.nvidia.com/datacenter/cloud-native/confidential-containers/latest/prerequisites.html): Required starting state — Kubernetes cluster, containerd, BIOS (hardware virtualization, ACS, IOMMU), host OS/kernel, and feature gates (e.g. KubeletPodResourcesGet) — before installing Kata and the GPU Operator. - -## Install -- [Quickstart Install](https://docs.nvidia.com/datacenter/cloud-native/confidential-containers/latest/install-quickstart.html): Minimal Helm steps to install Kata Containers and the NVIDIA GPU Operator and create the CC RuntimeClasses. -- [Detailed Install Guide](https://docs.nvidia.com/datacenter/cloud-native/confidential-containers/latest/confidential-containers-deploy.html): Full install with per-node configuration, labeling, and verification. - -## Run & configure -- [Run a Sample Workload](https://docs.nvidia.com/datacenter/cloud-native/confidential-containers/latest/run-sample-workload.html): Deploy cuda-vectoradd-kata.yaml on the CC RuntimeClass; success = `Test PASSED` in the pod logs. -- [Configuring Workloads](https://docs.nvidia.com/datacenter/cloud-native/confidential-containers/latest/configure-workloads.html): Workload spec options for confidential GPU pods, including how to attach a Kata agent security policy. -- [Managing Confidential Computing Mode](https://docs.nvidia.com/datacenter/cloud-native/confidential-containers/latest/configure-cc-mode.html): Turning GPU CC mode on/off and verifying cc.mode.state. - -## Attestation -- [Attestation](https://docs.nvidia.com/datacenter/cloud-native/confidential-containers/latest/attestation.html): Attestation as a requirement for secret release, with Trustee as the example verifier. Quickstart success signal: a policy-denied response confirms end-to-end connectivity. - -## Reference -- [Troubleshooting](https://docs.nvidia.com/datacenter/cloud-native/confidential-containers/latest/troubleshooting.html): Symptom → Cause → Fix for common CoCo failures. -- [Release Notes](https://docs.nvidia.com/datacenter/cloud-native/confidential-containers/latest/release-notes.html): Version history and known issues. -- [Licensing](https://docs.nvidia.com/datacenter/cloud-native/confidential-containers/latest/licensing.html): License information. diff --git a/confidential-containers/overview.rst b/confidential-containers/overview.rst deleted file mode 100644 index 4eac3ed73..000000000 --- a/confidential-containers/overview.rst +++ /dev/null @@ -1,310 +0,0 @@ -.. license-header - SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. - SPDX-License-Identifier: Apache-2.0 - - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - -.. headings # #, * *, =, -, ^, " - - -##################################################### -NVIDIA Confidential Containers Reference Architecture -##################################################### - -This documentation describes NVIDIA's reference architecture for deploying CNCF Confidential Containers on compliant Confidential Computing hardware and software. -For documentation navigation by role, refer to :doc:`Personas `. - -.. _confidential-containers-overview: - -********** -Background -********** - -NVIDIA GPUs power the training and deployment of Large Language Models (LLMs) that define the state of the art in AI reasoning and capability. -As organizations adopt these models in regulated industries such as financial services, healthcare, and the public sector, protecting model intellectual property and sensitive user data becomes essential. -The model deployment landscape is also evolving to include public clouds, enterprise on-premises, and edge. -A zero-trust posture on cloud-native platforms such as Kubernetes is essential to secure assets (model IP and enterprise private data) from untrusted infrastructure with privileged user access. - -Confidential Computing (CC) addresses this gap by using hardware-based Trusted Execution Environments (TEEs), such as AMD SEV-SNP and Intel TDX, with NVIDIA Confidential Computing capabilities to provide isolation, memory encryption, and integrity verification during processing. In addition to isolation, CC provides Remote Attestation, which allows workload owners to cryptographically verify the state of a TEE before providing secrets or sensitive data. - -`Confidential Containers `__ (CoCo) is the cloud-native approach of CC on Kubernetes. -The Confidential Containers project leverages Kata Containers to provide the sandboxing capabilities. -`Kata Containers `_ is an open-source project that provides lightweight Utility Virtual Machines (UVMs) that feel and perform like containers while providing strong workload isolation. Along with the Confidential Containers project, Kata enables the orchestration of secure, GPU-accelerated workloads in Kubernetes. - -.. _coco-use-cases: - -********* -Use Cases -********* - -The target for Confidential Containers is to enable model providers (closed and open source) and Enterprises to use the advancements of Gen AI, agnostic to the deployment model (Cloud, Enterprise, or Edge). - -* For Model Providers: It enables the expansion of reach by allowing expensive, proprietary model weights to be deployed on-site at customer data centers without exposing the intellectual property (IP) to the customer's infrastructure administrators. -* For Adopters: It provides low-latency access to state-of-the-art frontier models within their own sovereign environment, ensuring their private prompts and data never leave their controlled premises while maintaining the security of the model provider's IP. - -Some of the key use cases that CC and Confidential Containers enable are: - -* **Zero-Trust AI and IP Protection:** You can deploy proprietary models (such as LLMs) on third-party or private infrastructure. The model weights remain encrypted and are only decrypted inside the hardware-protected enclave, ensuring absolute IP protection from the host. -* **Data Clean Rooms:** This allows you to process sensitive enterprise data (such as financial analytics or healthcare records) securely. Neither the infrastructure provider nor the model builder can see the raw data. - -.. image:: graphics/CoCo-Sample-Workflow.png - :alt: Sample Workflow for Securing Model IP on Untrusted Infrastructure with CoCo - -*Sample Workflow for Securing Model IP on Untrusted Infrastructure with CoCo* - - -.. _coco-architecture: - -********************* -Architecture Overview -********************* - -Integrating open source and NVIDIA software components with the Confidential Computing capabilities of NVIDIA GPUs, this reference architecture is designed to be the secure and trusted deployment model for AI workloads. - -The key values of this architecture approach are: - -1. Built on Open Source Software (OSS) standards: this reference architecture is built on key OSS components such as Kata, Trustee, QEMU, OVMF, and Node Feature Discovery (NFD), along with NVIDIA components such as the NVIDIA GPU Operator. -2. Highest level of isolation: the Confidential Containers architecture is built on Kata containers, the industry standard for providing hardened sandbox isolation, and augmenting it with support for GPU passthrough to Kata containers makes the base of the Trusted Execution Environment (TEE). -3. Zero-trust execution with attestation: ensuring the trust of the model providers/data owners by providing a full-stack verification capability with attestation. - The integration of NVIDIA GPU attestation capabilities with Trustee based architecture, to provide composite attestation provides the base for secure, attestation based key-release for encrypted workloads, deployed inside the TEE. - -.. image:: graphics/CoCo-Reference-Architecture.png - :alt: High-Level Reference Architecture for Confidential Containers - :class: only-light - -.. image:: graphics/CoCo-Reference-Architecture-Dark.png - :class: only-dark - -*High-Level Reference Architecture for Confidential Containers* - -The above diagram shows the high-level reference architecture for Confidential Containers and -the key components that are used to deploy and manage Confidential Containers workloads. -The components are described in more detail in the next section. - -.. _coco-supported-platforms-components: - - -*********************************************** -Software Components for Confidential Containers -*********************************************** - -The following is a brief overview of the software components in NVIDIA's Reference Architecture for Confidential Containers. -Refer to the diagram above for a visual representation of the components. - - -**Kata Containers** - -Acts as the secure isolation layer by running standard Kubernetes Pods inside lightweight, hardware-isolated Utility Virtual Machines (UVMs) rather than sharing the untrusted host kernel. -`Kata Containers `_ is an open source project, which is integrated with the Kubernetes `Agent Sandbox `_ project, that delivers sandboxing capabilities. - -**Kata Deploy** - -Deployment mechanism (often managed with Helm) that installs the Kata runtime binaries, UVM images and kernels, and TEE-specific shims (such as ``kata-qemu-nvidia-gpu-snp`` or ``kata-qemu-nvidia-gpu-tdx``) onto the cluster's worker nodes. - -Refer to the `Kata Containers documentation `_ for more information. - -.. _coco-gpu-operator-components: - -**NVIDIA GPU Operator** - -Automates GPU lifecycle management. -For Confidential Containers, it securely provisions GPU support and handles VFIO-based GPU passthrough directly into the Kata confidential Virtual Machine (VM) without breaking the hardware trust boundary. - -The GPU Operator deploys the components needed to run Confidential Containers to simplify managing the software required for confidential computing, managing the Confidential Computing mode on GPUs, and deploying confidential container workloads. -The GPU Operator uses node labels to manage the deployment of components to the nodes in your cluster that should run Confidential Containers. -These components include: - -* NVIDIA Confidential Computing Manager (cc-manager) for Kubernetes: Sets the confidential computing (CC) mode on the NVIDIA GPUs. - By default, the Confidential Computing Manager will transition all NVIDIA GPUs to Confidential Computing mode, if they are not already in that mode. -* NVIDIA Kata Sandbox Device Plugin: Creates host-side Container Device Interface (CDI) specifications for GPU passthrough and discovers NVIDIA GPUs along with their capabilities, advertises these to Kubernetes, and allocates GPUs during pod deployment. - Allocatable GPU resources are advertised as type ``nvidia.com/pgpu`` by default. -* NVIDIA VFIO Manager: Binds discovered NVIDIA GPUs and NVSwitches to the vfio-pci driver for VFIO passthrough. - -Refer to the :doc:`NVIDIA GPU Operator ` documentation for more information on the NVIDIA GPU Operator or the :ref:`GPU Operator Cluster Topology Considerations ` section for more information on selecting nodes for Confidential Containers. - -**Node Feature Discovery (NFD)** - -Bootstraps the node by advertising the node features using labels to make sophisticated scheduling decisions, such as installing the Kata/CoCo stack only on the nodes that support the CC prerequisites for CPU and GPU. -This directs the Operator to install node feature rules that detect CPU security features and the NVIDIA GPU hardware. - -Refer to the `Node Feature Discovery documentation `_ for upstream usage and reference material. -The project source repository is `kubernetes-sigs/node-feature-discovery `_ on GitHub. -This component is typically deployed and managed by default by the GPU Operator. - -**Snapshotter (for example, Nydus)** - -Handles the container image "guest pull" functionality. -Used as a remote snapshotter, it bypasses image pulls on the host. -Instead, the snapshotter fetches and unpacks encrypted and signed container images directly inside the protected guest memory, keeping proprietary contents hidden and ensuring image integrity. - - -**Kata Agent and Agent Security Policy** - -Runs inside the guest VM to manage the container lifecycle while enforcing a strict, immutable agent security policy based on Rego (regorus). -This blocks the untrusted host from executing unauthorized commands, such as a malicious ``kubectl exec``. -For how to generate and attach a policy to a workload, refer to :ref:`Attach a Kata Agent Security Policy `. - -**Trustee and Attestation Service** - -Attestation and key brokering framework (which includes the Key Broker Service and Attestation Service). -It acts as the cryptographic gatekeeper, verifying hardware/software evidence and only releasing secrets if the environment is proven secure. - - -**Confidential Data Hub (CDH)** - -An in-guest component that securely receives sealed secrets from Trustee and transparently manages encrypted persistent storage and image decryption for the workload. - -**NVIDIA Runtime Container (NVRC)** - -A minimal hardened init system that securely bootstraps the guest environment, life cycles the kata-agent, provides health checks on started helper daemons while drastically reducing the attack surface. - - -.. _coco-gpu-operator-cluster-topology: - -GPU Operator Cluster Topology Considerations -============================================ - -The GPU Operator deploys and manages components for allocating and utilizing the GPU resources on your cluster. -Depending on how you configure the Operator, different components are deployed on the worker nodes. -When setting up Confidential Containers support, you can configure all the worker nodes in your cluster for running GPU workloads with Confidential Containers, or you can configure some nodes for Confidential Containers and the others for traditional containers. -This configuration is done through node labelling and configuration flags set during installation or by editing the ClusterPolicy object post installation. - -Consider the following example where node A is configured to run traditional containers and node B is configured to run confidential containers. - -.. list-table:: - :widths: 50 50 - :header-rows: 1 - - * - Node A - Traditional Container nodes receive the following software components - - Node B - Confidential Container nodes receive the following software components - * - * NVIDIA Driver Manager for Kubernetes - * NVIDIA Container Toolkit - * NVIDIA Device Plugin for Kubernetes - * NVIDIA DCGM and DCGM Exporter - * NVIDIA MIG Manager for Kubernetes - * Node Feature Discovery - * NVIDIA GPU Feature Discovery - - * NVIDIA Confidential Computing Manager for Kubernetes - * NVIDIA Kata Sandbox Device Plugin - * NVIDIA VFIO Manager - * Node Feature Discovery - -This configuration can be controlled through node labelling, as described in :doc:`Detailed Install Guide `. - -******************************************* -Supported Features and Deployment Scenarios -******************************************* - -The following features are supported with Confidential Containers: - -* Support for Confidential Container workloads as - - * :ref:`Single-GPU passthrough ` (one physical GPU per pod). - * :ref:`Multi-GPU passthrough ` on NVSwitch (NVLink) based HGX systems. - -.. note:: - - For both single and multi GPU Passthrough, all GPUs on the host must be configured for Confidential Computing. - For multi-GPU passthrough, all GPUs must be assigned to one Confidential Container virtual machine. - Configuring only some GPUs on a node for Confidential Computing is not supported. - - -* Composite :doc:`attestation ` using Trustee and the NVIDIA Remote Attestation Service (NRAS). -* Generating Kata Agent Security Policies. -* Use of `signed sealed secrets `_. -* Access to authenticated registries for container image guest-pull. -* Container image signature verification and encrypted container images. -* Ephemeral container data and image layer storage. -* Lifecycle management of Kata Containers through the `Kata Lifecycle Manager `_. - -More information on these features can be found in the `Confidential Containers documentation `__. - -.. _coco-limitations: - -**************************** -Limitations and Restrictions -**************************** - -* NVIDIA supports the GPU Operator and confidential computing with the containerd runtime only. - -* All GPUs on the host must be configured for Confidential Computing. - Configuring only a subset of GPUs on a node is not supported. - For multi-GPU passthrough, all GPUs must be assigned to a single confidential VM. - -* Nested virtualization is not supported. - Confidential Containers provides its own virtualization based on Kata Containers and must be installed directly on the host, not within a guest VM. - -* PCI peer-to-peer (P2P) DMA is unsupported because IOMMUFD does not yet support mapping hardware PCI BAR regions. - When a GPU is assigned as a VFIO PCI device, QEMU logs the following warnings at VM startup for each assigned device. - This is expected behavior and does not affect GPU functionality. - - .. code-block:: output - - qemu-system-x86_64: warning: IOMMU_IOAS_MAP failed: Bad address, PCI BAR? - qemu-system-x86_64: vfio_container_dma_map(0x560cb6cb1620, 0xe000000021000, 0x3000, 0x7f32ed55c000) = -14 (Bad address) - - Refer to the `QEMU IOMMUFD documentation `_ for more information. - -Security Considerations -======================= - -* Application security defects: Confidential Computing does not protect against threats within the confidential VM, including vulnerabilities in the application itself. - Applications must still follow security best practices such as input validation. - -* Control plane: Confidential Containers provides protections to limit the influence of the Kubernetes control plane. - However, applications may expose themselves to attack if they rely on control-plane-managed configuration. - -* Environment variables and ConfigMaps: Unless provisioned as sealed secrets using Trustee, orchestrator-provided environment variables and ConfigMaps remain untrusted and susceptible to manipulation. - -* Storage and volume mounts: Manipulating volume mounts can expose the workload to malicious untrusted host storage or deny access to required persistent data. - -* Physical attacks: Confidential Computing considers most physical attacks out of scope. - Kubernetes hosts should be in physically secure datacenters. - -* Availability: Confidential Computing does not provide availability guarantees. - Achieve availability through replication, which is standard practice in Kubernetes deployments. - -********** -Next Steps -********** - -To deploy on your cluster, start with the **Install** section: - -.. grid:: 2 - :gutter: 3 - - .. grid-item-card:: :octicon:`server;1.5em;sd-mr-1` Supported Platforms and Software Components - :link: supported-platforms - :link-type: doc - - Validated hardware, OS, and component versions. - - .. grid-item-card:: :octicon:`checklist;1.5em;sd-mr-1` Prerequisites - :link: prerequisites - :link-type: doc - - Prepare worker nodes and the Kubernetes cluster. - - .. grid-item-card:: :octicon:`rocket;1.5em;sd-mr-1` Detailed Install Guide - :link: confidential-containers-deploy - :link-type: doc - - Install Kata Containers and the NVIDIA GPU Operator on Kubernetes. - - .. grid-item-card:: :octicon:`play;1.5em;sd-mr-1` Run a Sample Workload - :link: run-sample-workload - :link-type: doc - - Verify the deployment; success is ``Test PASSED`` in pod logs. - -After installation, refer to the **Configuration** section for workload configuration, CC mode management, and attestation. diff --git a/confidential-containers/personas.rst b/confidential-containers/personas.rst deleted file mode 100644 index ac39f0371..000000000 --- a/confidential-containers/personas.rst +++ /dev/null @@ -1,160 +0,0 @@ -.. license-header - SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. - SPDX-License-Identifier: Apache-2.0 - - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - -.. headings # #, * *, =, -, ^, " - -.. _coco-using-this-guide: - -######## -Personas -######## - -This page provides an overview of the prior knowledge recommended before implementing the architecture, the personas who own each part of the deployment, and how to navigate this documentation. - -****************** -Before You Begin -****************** - -This documentation describes NVIDIA's reference architecture and deployment recommendations for the upstream `CNCF Confidential Containers project `_ with NVIDIA GPUs. -Understanding the upstream project's goals, architecture, and threat model will give you the context needed to understand architecture decisions described in this documentation. - -Before using this documentation, you should be familiar with: - -* Confidential Containers concepts outlined in the upstream `Confidential Containers documentation `__, including the trust model, attestation flow, and key features such as sealed secrets and encrypted container images. - Start there if you are new to Confidential Computing on Kubernetes. -* Kubernetes administration and deployment experience, including deploying workloads, using ``kubectl``, and installing components with Helm. - Refer to the `Kubernetes documentation `_ if you need a foundation. -* Confidential Computing hardware, familiarity with AMD SEV-SNP or Intel TDX, and an understanding of which technology your target hardware uses. - -The documentation on this site is specific for deploying Confidential Containers on NVIDIA GPUs with Kata Containers and the NVIDIA GPU Operator. -It covers the steps you take to enable and configure these components on your cluster to align with the NVIDIA Reference Architecture for Confidential Containers. -For more advanced Confidential Containers topics, refer to the upstream `Confidential Containers documentation `__. - -******** -Personas -******** - -The personas used throughout this documentation describe who is responsible for each stage of enabling and managing Confidential Computing, from hardware selection through workload deployment. -Depending on your role, you may complete several sections or only a subset. - -.. list-table:: - :header-rows: 1 - :widths: 28 42 30 - - * - Persona - - Responsibilities - - Start here - * - :ref:`Hardware IT Administrator ` - - Selects Confidential Computing-capable CPU and GPU hardware and configures BIOS/UEFI settings. - - :doc:`Supported Platforms ` - * - :ref:`Host OS Administrator ` - - Prepares the host operating system after hardware and BIOS configuration are complete. - - :doc:`Supported Platforms ` - * - :ref:`Kubernetes Cluster Administrator ` - - Installs and manages the Kubernetes cluster and the Confidential Containers software stack. - - :doc:`Prerequisites ` - * - :ref:`Security Engineer ` - - Validates Confidential Computing configuration, attestation policy, agent security policy, and secret release for workloads. - - :doc:`Attestation Quickstart ` - * - :ref:`Container User ` - - Deploys confidential GPU workloads on a prepared cluster, including generating and attaching an agent security policy. - - :doc:`Configuring Workloads ` - -.. _coco-persona-hardware-it-administrator: - -*************************** -Hardware IT Administrator -*************************** - -The Hardware IT Administrator is near the beginning of the Confidential Computing workflow. -This persona selects the correct CPU and GPU part numbers and configures BIOS/UEFI settings for subsequent steps. -Typical roles include system architect and IT administrator. - -Relevant pages in this documentation: - -* :doc:`Supported Platforms `: validated CPU, GPU, OS, and component version combinations that NVIDIA has tested with Confidential Containers. - -For BIOS configuration and hardware setup, refer to the `NVIDIA Confidential Computing Deployment Guide `_ *Hardware IT Administrator* section. - -.. _coco-persona-host-os-administrator: - -********************** -Host OS Administrator -********************** - -The Host OS Administrator receives a system with BIOS/UEFI configured for Confidential Computing and prepares the host operating system. -This persona is responsible for host OS selection, initial configuration, and validation before confidential workloads can run. -Typical roles include system architect, cloud administrator, or advanced on-premises user. - -Relevant pages in this documentation: - -* :doc:`Supported Platforms `: validated host OS and kernel versions. - -For host OS setup, refer to the `NVIDIA Confidential Computing Deployment Guide `_ *Host OS Administrator* section. - -.. _coco-persona-kubernetes-cluster-administrator: - -******************************** -Kubernetes Cluster Administrator -******************************** - -The Kubernetes Cluster Administrator is responsible for installing and managing the Kubernetes cluster and the Confidential Containers software stack. -This persona could be a platform engineer with cluster-admin access to the API, host access to worker nodes, and familiarity with Helm and ``kubectl``. -This persona performs the initial deployment and is responsible for day-two operations such as upgrades and Confidential Computing mode changes. - -Relevant pages: - -* :doc:`Reference Architecture `: understand the software components and how they fit together. -* :doc:`Prerequisites `: prepare worker nodes and the Kubernetes cluster. -* :doc:`Quickstart Install `: minimal steps to install Kata Containers and the GPU Operator. -* :doc:`Detailed Install Guide `: install with per-node labeling and additional configuration options. -* :doc:`Run a Sample Workload `: confirm the deployment was successful. -* :doc:`Managing the Confidential Computing Mode `: change the CC mode on GPUs at the cluster or node level as needed. -* :doc:`Troubleshooting `: resolve install and deploy failures (for example :ref:`Insufficient nvidia.com/pgpu `). - -.. _coco-persona-security-engineer: - -***************** -Security Engineer -***************** - -The Security Engineer might or might not be the Kubernetes Cluster Administrator. -Their work may cover attestation services, reference values, policies, and secret release for confidential workloads. -Typical roles include security engineer, platform security, or DevSecOps. - -Relevant pages: - -* :doc:`Reference Architecture `: understand the use cases, trust model, and how workloads are isolated from the infrastructure. -* :doc:`Attestation Quickstart `: stand up a local Trustee instance and verify connectivity. - Attestation is required for workloads that use secrets, encrypted container images, or authenticated registries. - Review the :ref:`Kata agent security policy ` so the untrusted host cannot issue unauthorized Agent API calls into the guest. - -For production attestation workflows, secret management, and policy configuration, refer to the upstream `Confidential Containers attestation documentation `_. - -.. _coco-persona-container-user: - -************** -Container User -************** - -The Container User deploys confidential applications on a system that is already configured for Confidential Computing. -In this documentation, that means deploying confidential GPU workloads with Kubernetes manifests on a cluster that the Kubernetes Cluster Administrator has prepared. -This persona works primarily with Kubernetes workload manifests and does not require host access to worker nodes. - -Relevant pages: - -* :doc:`Configuring Workloads `: runtime class selection, GPU and NVSwitch resource types, single- or multi-GPU passthrough manifests, and attaching a Kata agent security policy. -* :doc:`Run a Sample Workload `: run the reference workload to confirm the cluster is ready before deploying your own application. diff --git a/confidential-containers/prerequisites.rst b/confidential-containers/prerequisites.rst deleted file mode 100644 index c4a5b6066..000000000 --- a/confidential-containers/prerequisites.rst +++ /dev/null @@ -1,304 +0,0 @@ -.. license-header - SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. - SPDX-License-Identifier: Apache-2.0 - - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - -.. headings # #, * *, =, -, ^, " - - -.. _coco-prerequisites: - -############# -Prerequisites -############# - -As a :ref:`Kubernetes Cluster Administrator `, prepare hosts and the Kubernetes cluster before you install Kata Containers and the NVIDIA GPU Operator. -You perform most steps in this section. -If you do not have access to host firmware, coordinate with your :ref:`Hardware IT Administrator ` or :ref:`Host OS Administrator ` to confirm or implement hardware prerequisites. - -Use the following checklists as at-a-glance summary and supplement to the :doc:`Supported Platforms ` page. - -**Hardware Configuration Requirements** - -For validated hardware, refer to :doc:`Supported Platforms `. - -.. list-table:: - :header-rows: 1 - :widths: 30 70 - - * - Configuration Requirement - - Details - * - :ref:`Hardware virtualization and ACS enabled ` - - Hardware virtualization and ACS enabled in host BIOS - * - :ref:`IOMMU enabled ` - - IOMMU enabled on each host through the kernel command line (``amd_iommu=on`` or ``intel_iommu=on``) - * - :ref:`No host NVIDIA GPU drivers ` - - No NVIDIA GPU drivers installed or loaded on worker hosts. - -**Cluster Configuration Requirements** - -For validated software components, refer to :doc:`Supported Platforms `. - -.. list-table:: - :header-rows: 1 - :widths: 30 70 - - * - Configuration Requirement - - Details - * - :ref:`A Kubernetes cluster and cluster administrator access ` - - Cluster administrator access to a Kubernetes cluster running a supported version. - * - :ref:`Helm installed ` - - Helm installed on your cluster administration system - * - :ref:`Kubelet configured ` - - Enable ``KubeletPodResourcesGet`` (required before Kubernetes v1.34) and ``RuntimeClassInImageCriApi`` feature gates; set ``runtimeRequestTimeout: 20m`` on GPU worker nodes - -******************************************** -Hardware and BIOS Configuration Requirements -******************************************** - -.. _coco-prereq-supported-platform: - -Supported Platform -================== - -Your hosts must use a platform validated for Confidential Computing in :doc:`Supported Platforms `. -Confirm with your :ref:`Hardware IT Administrator ` and :ref:`Host OS Administrator ` that any platform-specific BIOS, firmware, or OS steps are in place before continuing. - -.. _coco-prereq-hw-virtualization: - -Hardware Virtualization and ACS Enabled -======================================= - -Confirm with your :ref:`Hardware IT Administrator ` that your hosts are configured to enable hardware virtualization and Access Control Services (ACS). -With some AMD CPUs and BIOSes, ACS might be grouped under Advanced Error Reporting (AER). -Enable these features in the host BIOS if they are not already enabled. - -.. _coco-prereq-iommu: - -IOMMU Enabled -============= - -IOMMU must be enabled on all hosts that will run Confidential Containers workloads. - -#. Check whether IOMMU is already enabled: - - .. code-block:: console - - $ ls /sys/kernel/iommu_groups - - If the output lists numbered groups (``0``, ``1``, and so on), IOMMU is enabled. - - If the output is empty or the directory is missing, IOMMU is not enabled. - -#. If IOMMU is not enabled, add the appropriate kernel command-line argument to ``/etc/default/grub``: - - * ``amd_iommu=on`` for AMD CPUs - * ``intel_iommu=on`` for Intel CPUs - - .. tab-set:: - - .. tab-item:: AMD-based system (SNP) - :sync: amd-snp - - .. code-block:: console - - ... - GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on modprobe.blacklist=nouveau" - ... - - .. tab-item:: Intel-based system (TDX) - :sync: intel-tdx - - .. code-block:: console - - ... - GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on modprobe.blacklist=nouveau" - ... - -#. Update the bootloader configuration: - - .. code-block:: console - - $ sudo update-grub - - *Example Output:* - - .. code-block:: output - - Sourcing file `/etc/default/grub' - Generating grub configuration file ... - Found linux image: /boot/vmlinuz-5.15.0-generic - Found initrd image: /boot/initrd.img-5.15.0-generic - done - -#. Reboot the host. - -.. note:: - - After configuring IOMMU, you might see QEMU warnings about PCI P2P DMA when running GPU workloads. - These are expected and can be safely ignored. - Refer to :ref:`coco-limitations` for details. - -.. _coco-prereq-no-host-drivers: - -Ensure No Host NVIDIA GPU Drivers Are Present -============================================= - -Confidential Containers pass GPUs to the confidential virtual machine through VFIO. -Host-installed NVIDIA drivers prevent VFIO from binding the devices and must not be present on those hosts. -In this architecture, the NVIDIA GPU Operator handles GPU driver installation and lifecycle management when you follow the :doc:`Detailed Install Guide `. - -#. On each host, check whether NVIDIA GPU drivers are loaded: - - .. code-block:: console - - $ lsmod | grep nvidia - - If the command produces no output, no NVIDIA GPU drivers are loaded. - -#. If drivers are installed or loaded on any host, remove them. - - Refer to `Removing the Driver `_ in the NVIDIA Driver Installation Guide. - -********************************************* -Kubernetes Cluster Configuration Requirements -********************************************* - -The following sections describe requirements for worker nodes and for the system you use for cluster administration. - -.. _coco-prereq-cluster-admin: - -Kubernetes Cluster and Cluster Administrator Access -=================================================== - -You must have cluster administrator access to a Kubernetes cluster running a supported Kubernetes version. -Refer to the :ref:`Supported Software Components ` section in :doc:`Supported Platforms ` for supported Kubernetes and component versions. - -.. _coco-prereq-helm: - -Helm -==== - -Helm is used to install the NVIDIA GPU Operator and Kata Containers. - -Verify that Helm is installed on the system you use for cluster administration: - -.. code-block:: console - - $ helm version - -*Example Output:* - -.. code-block:: output - - version.BuildInfo{Version:"v3.14.0", GitCommit:"...", GitTreeState:"clean", GoVersion:"go1.21.6"} - -Your exact version details may vary. - -If Helm is not installed or the command is not found, refer to the `Helm documentation `_ for installation instructions. - -.. _coco-prereq-kubelet: -.. _configure-image-pull-timeouts: - -Kubelet Configured -================== - -On GPU worker nodes, the kubelet configuration (typically ``/var/lib/kubelet/config.yaml``) must include the required feature gates and an extended image pull timeout. - -Confidential Containers require these kubelet feature gates: - -* ``KubeletPodResourcesGet``: Allows the Kata runtime to query the kubelet Pod Resources API and discover GPUs allocated to a sandbox. - -* ``RuntimeClassInImageCriApi``: Alpha since Kubernetes v1.29; required for pods that use multiple snapshotters side by side. - -On Kubernetes v1.34 and later, ``KubeletPodResourcesGet`` is enabled by default. -On versions before v1.34, enable it explicitly. -``RuntimeClassInImageCriApi`` must be enabled explicitly on all supported versions. - -Increase the ``runtimeRequestTimeout`` from the 2-minute default to ``20m`` to avoid timeouts when pulling large GPU workload images. -If a pull exceeds the timeout before the container is running, the kubelet de-allocates the pod. -Actual pull duration varies with image size and network throughput, so this guide uses 20 minutes as a conservative ceiling that accommodates most workload images. - -Apply these settings as follows: - -#. Open the kubelet configuration file: - - .. code-block:: console - - $ sudo nano /var/lib/kubelet/config.yaml - - This is typically located at ``/var/lib/kubelet/config.yaml``, but your configuration file may be in a different location. - -#. Add the required settings to the kubelet configuration file. - Select the tab that matches your Kubernetes version: - - .. tab-set:: - - .. tab-item:: Kubernetes v1.34 and later - :sync: k8s-1-34-plus - - .. code-block:: yaml - - apiVersion: kubelet.config.k8s.io/v1beta1 - kind: KubeletConfiguration - featureGates: - RuntimeClassInImageCriApi: true - runtimeRequestTimeout: 20m - - .. tab-item:: Kubernetes earlier than v1.34 - :sync: k8s-pre-1-34 - - .. code-block:: yaml - - apiVersion: kubelet.config.k8s.io/v1beta1 - kind: KubeletConfiguration - featureGates: - KubeletPodResourcesGet: true - RuntimeClassInImageCriApi: true - runtimeRequestTimeout: 20m - - If your kubelet configuration already defines ``featureGates`` or ``runtimeRequestTimeout``, merge these settings into the existing file instead of replacing it. - -#. Restart the kubelet service: - - .. code-block:: console - - $ sudo systemctl restart kubelet - -#. Confirm the kubelet restarted cleanly with the new configuration: - - .. code-block:: console - - $ systemctl is-active kubelet - - *Example Output:* - - .. code-block:: output - - active - - A result of ``active`` confirms the kubelet restarted successfully. - If it reports ``activating`` or ``failed``, inspect ``sudo systemctl status kubelet`` and ``sudo journalctl -u kubelet`` for configuration errors before continuing. - -.. note:: - - If you need a timeout longer than 1200 seconds (20 minutes), consider also adjust the Kata Agent ``image_pull_timeout``. - This setting controls the Confidential Data Hub image pull API timeout in seconds. - Add the ``agent.image_pull_timeout`` kernel parameter to your shim configuration, or pass a value in the pod annotation ``io.katacontainers.config.hypervisor.kernel_params``. - -********** -Next Steps -********** - -After completing the prerequisites, proceed to :doc:`Quickstart Install ` for a minimal install, or :doc:`Detailed Install Guide ` for full configuration details. diff --git a/confidential-containers/release-notes.rst b/confidential-containers/release-notes.rst deleted file mode 100644 index 25dd66e60..000000000 --- a/confidential-containers/release-notes.rst +++ /dev/null @@ -1,146 +0,0 @@ -.. license-header - SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. - SPDX-License-Identifier: Apache-2.0 - - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - -.. headings # #, * *, =, -, ^, " - -.. _coco-release-notes: - -############# -Release Notes -############# - -This document describes the new features and known issues for the NVIDIA Confidential Containers Reference Architecture. - ----- - -.. _coco-v1.1.0: - -1.1.0 -===== - -Release Date: August 11, 2026 - -This release expands hardware coverage and updates the validated software stack. - -New Features ------------- - -* Added support for the NVIDIA HGX B300 platform with both single-GPU and multi-GPU passthrough. - -* Added support for Ubuntu 26.04 as a host operating system. - -* Added support for the following software components: - - * Kata Containers ${kata_version} - * Kata Lifecycle Manager 0.1.8 - * containerd 2.3.x - -* This release has General Availability support for most platforms running Red Hat OpenShift Sandboxed Containers 1.13. - Refer to `Confidential containers: feature availability by OpenShift Container Platform version `__. - - -Docs Changelog --------------- - -The :ref:`coco-install-kata-chart` procedure was updated for this release. -Changes include: - -* Installs ``kata-deploy`` with a values file instead of inline ``--set`` flags. - -* Includes a new sample values file, :file:`samples/kata-nvidia-gpu-values.yaml`, that configures the ``kata-deploy`` Helm chart for the NVIDIA Confidential Containers reference architecture (NVIDIA GPU shims only, NFD disabled, ``nydus`` snapshotter, and per-shim runtime class node selectors). - -* Adds a readiness verification step using ``kubectl rollout status ds/kata-deploy``. This step relies on the readiness reporting in Kata Containers and lets you confirm that ``kata-deploy`` has finished extracting artifacts and restarting containerd on every node before continuing. - -Post-Release Documentation Updates ----------------------------------- - -* Renamed the supported platforms page to :ref:`Supported Platforms and Software Components `. -* Documented attaching a Kata agent security policy for attested production workloads. - Refer to :ref:`Attach a Kata Agent Security Policy `. -* Split the software matrix into cluster prerequisites, Kata-provided guest and runtime artifacts, and separately deployed components. -* Recorded the distroless guest payload: NVRC, the NVIDIA GPU driver in the guest, and guest-components. -* Updated the guest kernel and QEMU versions to match the Kata Containers artifacts this architecture installs. -* Replaced the Key Broker Service protocol version with Trustee ${trustee_version} as the separately deployed attestation component. - The :doc:`Attestation ` quickstart clones that Trustee tag, documents Compose image pins for KBS, AS, and RVPS to that commit, and pulls the matching ``kbs-client`` artifact. -* Pinned ``genpolicy`` to ${genpolicy_version} and pointed the download and README links at that Kata Containers release. -* Restored ``--wait`` on the detailed ``kata-deploy`` install command and attributed the disabled NFD deployment to the values file. -* Corrected the NFD setting in :file:`samples/kata-nvidia-gpu-values.yaml`. - The sample used a key that the ``kata-deploy`` chart ignores, so the chart default kept NFD disabled instead of the sample. - ----- - -.. _coco-v1.0.0: - -***** -1.0.0 -***** - -Release Date: April 29, 2026 - -This is the initial general availability (GA) release of the NVIDIA Confidential Containers Reference Architecture, a validated deployment model for running GPU-accelerated AI workloads inside hardware-enforced Trusted Execution Environments (TEEs). -It is designed for organizations in regulated industries that require strong isolation and cryptographic verification to protect model intellectual property and sensitive data on untrusted infrastructure. - -The architecture combines NVIDIA GPU Confidential Computing, Kata Containers, and the NVIDIA GPU Operator to provide a secure, attestable, Kubernetes-native platform for confidential AI workloads. - -Key Features -============ - -* This release supports HGX platforms with: - - - NVIDIA H100 (single-GPU passthrough) - - NVIDIA H200 (single-GPU passthrough) - - NVIDIA H100 Protected PCIe (multi-GPU passthrough) - - NVIDIA H200 Protected PCIe (multi-GPU passthrough) - - NVIDIA B200 (single-GPU and multi-GPU passthrough) - - NVIDIA RTX Pro 6000 BSE (single-GPU passthrough) - - AMD Genoa / Milan CPUs with Ubuntu 25.10 (kernel 6.17+) for SEV-SNP - - Intel Emerald Rapids / Granite Rapids CPUs with Ubuntu 25.10 (kernel 6.17+) for TDX - -* This release supports the following software components: - - - NVIDIA GPU Operator v26.3.1 - - Kata Containers 3.29 (installed with the ``kata-deploy`` Helm chart) - - Kata Lifecycle Manager 0.1.4 - - Key Broker Service (KBS) protocol 0.4.0 - - QEMU 10.1 + Patches - - OVMF edk2-stable202511 - - Containerd 2.2.2 - - Kubernetes 1.32+ - - Ubuntu 25.10 (host OS) - -* This release has Technology Preview support for Red Hat OpenShift Sandboxed Containers 1.12. - - -Limitations and Restrictions -============================ - -* NVIDIA supports the GPU Operator and confidential computing with the containerd runtime only. - -* All GPUs on the host must be configured for Confidential Computing. - Configuring only a subset of GPUs on a node is not supported. - For multi-GPU passthrough, all GPUs must be assigned to a single confidential VM. - -.. _coco-ea: - -Early Access Release -==================== - -Release Date: December 22, 2025 - - -The documentation for the early access release was published as part of the GPU Operator v25.10 release. -Refer to `Deploy Confidential Containers with NVIDIA GPU Operator `__. - diff --git a/confidential-containers/run-sample-workload.rst b/confidential-containers/run-sample-workload.rst deleted file mode 100644 index ea4a3c5d4..000000000 --- a/confidential-containers/run-sample-workload.rst +++ /dev/null @@ -1,201 +0,0 @@ -.. license-header - SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. - SPDX-License-Identifier: Apache-2.0 - - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - -.. headings # #, * *, =, -, ^, " - - -.. _coco-run-sample-workload: - -##################### -Run a Sample Workload -##################### - -As a :ref:`Kubernetes Cluster Administrator `, use this page to verify your installation and run a sample workload. -:ref:`Container User ` personas can also run the sample workload to confirm the cluster is ready before deploying applications. - -Verify your Confidential Container setup by running a basic single-GPU sample workload inside a Confidential Container. - -This page assumes that you have completed :doc:`Prerequisites ` and either :doc:`Quickstart Install ` or :doc:`Detailed Install Guide `. -Your cluster should have ``kata-qemu-nvidia-gpu-snp`` and ``kata-qemu-nvidia-gpu-tdx`` runtime classes installed, and GPU Operator operands (including the Confidential Computing Manager, Kata Sandbox Device Plugin, and VFIO Manager) running on your nodes. - -This page intentionally uses the simplest possible manifest so that you can confirm the deployment end-to-end. -It is not a production workload template. -For runtime class selection, resource type naming, multi-GPU passthrough, and additional manifest patterns, refer to :doc:`Configuring Workloads `. - -#. Create a file named ``cuda-vectoradd-kata.yaml`` with a sample manifest for your system: - - .. tab-set:: - - .. tab-item:: AMD-based system (SNP) - :sync: amd-snp - - .. code-block:: yaml - :emphasize-lines: 7,14 - - apiVersion: v1 - kind: Pod - metadata: - name: cuda-vectoradd-kata - namespace: default - spec: - runtimeClassName: kata-qemu-nvidia-gpu-snp - restartPolicy: Never - containers: - - name: cuda-vectoradd - image: "nvcr.io/nvidia/k8s/cuda-sample:vectoradd-cuda12.5.0-ubuntu22.04" - resources: - limits: - nvidia.com/pgpu: "1" # for single GPU passthrough - memory: 16Gi - - .. tab-item:: Intel-based system (TDX) - :sync: intel-tdx - - .. code-block:: yaml - :emphasize-lines: 7,14 - - apiVersion: v1 - kind: Pod - metadata: - name: cuda-vectoradd-kata - namespace: default - spec: - runtimeClassName: kata-qemu-nvidia-gpu-tdx - restartPolicy: Never - containers: - - name: cuda-vectoradd - image: "nvcr.io/nvidia/k8s/cuda-sample:vectoradd-cuda12.5.0-ubuntu22.04" - resources: - limits: - nvidia.com/pgpu: "1" # for single GPU passthrough - memory: 16Gi - - The following is a brief list of the options available for the manifest: - - * Runtime class: Use ``kata-qemu-nvidia-gpu-snp`` on AMD-based systems or ``kata-qemu-nvidia-gpu-tdx`` on Intel-based systems. - * GPU resource type: The sample requests ``nvidia.com/pgpu``, which is the default resource name advertised by the NVIDIA Kata Sandbox Device Plugin. - If your cluster was installed with the ``P_GPU_ALIAS=""`` setting, replace it with the model-specific name advertised on your node, for example ``nvidia.com/GH100_H200_141GB``. - - Refer to :doc:`Configuring Confidential Container Workloads ` for additional guidance on each option. - -#. Create the pod: - - .. code-block:: console - - $ kubectl apply -f cuda-vectoradd-kata.yaml - - *Example Output:* - - .. code-block:: output - - pod/cuda-vectoradd-kata created - -#. Verify the pod is running: - - .. code-block:: console - - $ kubectl get pod cuda-vectoradd-kata - - *Example Output:* - - .. code-block:: output - - NAME READY STATUS RESTARTS AGE - cuda-vectoradd-kata 1/1 Running 0 10s - - The pod could also say ``Completed`` if the container already completed successfully. - - If the pod stays ``Pending`` for more than a few minutes, use the :doc:`Troubleshooting ` guide for more details on viewing logs and potential causes for the pod being stuck. - -#. View the logs from the pod after the container starts: - - .. code-block:: console - - $ kubectl logs -n default cuda-vectoradd-kata - - *Example Output:* - - .. code-block:: output - - [Vector addition of 50000 elements] - Copy input data from the host memory to the CUDA device - CUDA kernel launch with 196 blocks of 256 threads - Copy output data from the CUDA device to the host memory - Test PASSED - Done - - The output should include ``Test PASSED`` if the container completed successfully. - This means that your cluster is configured to deploy GPU workloads in the Kata container runtime on nodes configured for Confidential Computing. - - If you do not see any log output, the pod may still be running. - Use the command in the previous step to check the pod status. - -#. Optionally, you can verify the sample app was running the Kata container runtime by checking the pod details: - - .. code-block:: console - - $ kubectl describe pod cuda-vectoradd-kata - - *Example Output:* - - .. code-block:: output - - Name: cuda-vectoradd-kata - Namespace: default - Priority: 0 - Runtime Class Name: kata-qemu-nvidia-gpu-tdx - - ... - - Events: - Type Reason Age From Message - ---- ------ ---- ---- ------- - Normal Scheduled 95s default-scheduler Successfully assigned default/cuda-vectoradd-kata to dellr760tdx - Normal Pulled 71s kubelet Container image "nvcr.io/nvidia/k8s/cuda-sample:vectoradd-cuda12.5.0-ubuntu22.04" already present on machine - Normal Created 71s kubelet Created container: cuda-vectoradd - Normal Started 68s kubelet Started container cuda-vectoradd - - The ``Runtime Class Name`` should match the runtime class used to create the pod and you will see that the pod ran successfully. - The example output shows ``Runtime Class Name: kata-qemu-nvidia-gpu-tdx``. - - -To clean up, delete the pod: - - .. code-block:: console - - $ kubectl delete -f cuda-vectoradd-kata.yaml - - - -********** -Next Steps -********** - -.. note:: - - You have verified that a GPU workload runs on the confidential runtime. This is the end of the - deployment path covered by this guide. - - Attestation is what cryptographically verifies the TEE and releases secrets to a - production workload. For attestation concepts and a local - connectivity test, see the :doc:`Attestation ` quickstart. For production attestation - deployment, refer to the upstream `Confidential Containers NVIDIA attestation guide - `__. - -If you'd like to continue to learn about Confidential Container configuration, review the following pages: - -* Refer to :doc:`Configuring Workloads ` for runtime class selection, resource types, and multi-GPU passthrough manifests. -* Refer to :doc:`Managing the Confidential Computing Mode ` to change the CC mode on GPUs at the cluster or node level. diff --git a/confidential-containers/supported-platforms.rst b/confidential-containers/supported-platforms.rst deleted file mode 100644 index 3b4f4489b..000000000 --- a/confidential-containers/supported-platforms.rst +++ /dev/null @@ -1,195 +0,0 @@ -.. license-header - SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. - SPDX-License-Identifier: Apache-2.0 - - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - -.. headings # #, * *, =, -, ^, " - -.. _coco-supported-platforms: - -############################################## -Supported Platforms and Software Components -############################################## - -Following are the platforms supported by the NVIDIA Confidential Containers Reference Architecture. - -This page is relevant to the following users: - -* The :ref:`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 ` uses the hardware tables to confirm validated host OS and kernel versions. -* The :ref:`Kubernetes Cluster Administrator ` uses the component matrix to confirm supported versions. - -******** -Hardware -******** - -NVIDIA GPUs -=========== - -.. list-table:: - :header-rows: 1 - :widths: 50 50 - - * - GPU - - Passthrough - - * - NVIDIA H100 - - Single-GPU - - * - NVIDIA H200 - - Single-GPU - - * - NVIDIA H100 Protected PCIe (PPCIe) - - Multi-GPU - - * - NVIDIA H200 Protected PCIe (PPCIe) - - Multi-GPU - - * - NVIDIA B200 - - Single-GPU, Multi-GPU - - * - NVIDIA HGX B300 - - Single-GPU, Multi-GPU - - * - NVIDIA RTX Pro 6000 BSE - - Single-GPU - -.. note:: - - :ref:`Multi-GPU passthrough ` on NVIDIA Hopper HGX systems requires that you set the Confidential Computing mode to ``ppcie`` mode. - Refer to :doc:`Managing the Confidential Computing Mode ` for details. - -.. note:: - - 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. - -Host Platforms -============== - -.. flat-table:: - :header-rows: 1 - - * - CPU Platform - - TEE - - Host Operating System - - Host Kernel Version - * - AMD Genoa / Milan - - AMD SEV-SNP - - Ubuntu 25.10 or 26.04 - - 6.17+ - * - Intel Emerald Rapids (ER) / Granite Rapids (GR) - - Intel TDX - - Ubuntu 25.10 or 26.04 - - 6.17+ - -For additional information on node configuration, refer to the `Confidential Computing Deployment Guide `_ for information about supported NVIDIA GPUs, such as the NVIDIA Hopper H100. - -The following topics in the deployment guide apply to a cloud-native environment: - -* Hardware selection and initial hardware configuration, such as BIOS settings. -* Host operating system selection, initial configuration, and validation. - -When following the cloud-native sections in the deployment guide linked above, use Ubuntu 25.10 or 26.04 as the host OS with its default kernel version and configuration. - -For additional resources on machine setup: - -* Refer to the `NVIDIA Trusted Computing Solutions website `_. -* Refer to the :doc:`Licensing ` page for more information on the licensing requirements for NVIDIA Confidential Computing capabilities. - -.. _coco-supported-software-components: - - -***************************** -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 `__ - - 1.32 \+ - - Prerequisite, must already be installed on the cluster hosts. - * - `containerd `__ - - 2.3.x - - Prerequisite, must already be installed on the cluster hosts. - * - `Kata Containers `__ - - ${kata_version} - - Installed with the ``kata-deploy`` Helm chart by following the :doc:`Quickstart Install ` or :doc:`Detailed Install Guide `. - * - `NVIDIA GPU Operator `__ and its components. - - Refer to the :ref:`GPU 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 ` or :doc:`Detailed Install Guide `. - -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, with `NVRC ${nvrc_version} `__, - NVIDIA GPU driver ${guest_nvidia_driver_version}, and - `guest-components ${guest_components_version} `__ artifacts. - * - Guest kernel - - ${guest_kernel_version} - * - `OVMF `__ - - edk2-stable202511 - * - `QEMU `__ - - ${qemu_version} \+ Patches - -Separately Deployed Components and Interfaces -============================================= - -The following components and interfaces are not installed by the :doc:`Quickstart Install ` or :doc:`Detailed Install Guide `. - -.. flat-table:: - :header-rows: 1 - - * - Interface or Component - - Version - - When It Is Needed - - How It Is Provided - * - `Trustee `__ - - ${trustee_version} - - Required for attestation and secret or key release. - This architecture validates Trustee ${trustee_version} with guest-components ${guest_components_version} in the Kata guest. - - The :doc:`Attestation ` quickstart installs a local evaluation Trustee ${trustee_version}. - Deploy a production Trustee separately by following the upstream Confidential Containers documentation. - * - `Kata 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 `__ - - ${genpolicy_version} - - Used to generate an agent security policy for attested production workloads. - Refer to :ref:`Attach a Kata Agent Security Policy `. - - Download ``genpolicy`` ${genpolicy_version} from the `Kata Containers ${genpolicy_version} release `__. - -Users may leverage `Red Hat OpenShift Sandboxed Containers `__ to deploy Confidential Containers. diff --git a/confidential-containers/troubleshooting.rst b/confidential-containers/troubleshooting.rst deleted file mode 100644 index 667ac4218..000000000 --- a/confidential-containers/troubleshooting.rst +++ /dev/null @@ -1,496 +0,0 @@ -.. license-header - SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. - SPDX-License-Identifier: Apache-2.0 - - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - -.. headings # #, * *, =, -, ^, " - -.. _coco-deploy-troubleshooting: - -############### -Troubleshooting -############### - -Use this page when Confidential Containers installation or workload deployment steps fail. - -Refer to the :doc:`NVIDIA GPU Operator troubleshooting guide ` for general operator issues such as driver daemonsets, the container toolkit, and validator pods. -The sections below cover Confidential Containers-specific deploy failures: CC node labels, Kata runtime installation, and host prerequisites. - -If these steps do not resolve your issue, refer to :ref:`Getting Help `. - -.. list-table:: - :header-rows: 1 - :widths: 38 35 27 - - * - Symptom - - Cause - - Fix - * - :ref:`Pod stuck in Pending with Insufficient nvidia.com/pgpu ` - - Node not labeled for Confidential Containers, GPUs not bound to ``vfio-pci``, or all GPUs already allocated. - - Check operands running, verify ``vm-passthrough`` label, confirm ``vfio-pci`` binding. - * - :ref:`Pod stuck in ContainerCreating with device cold plug failed ` - - ``KubeletPodResourcesGet`` feature gate not enabled on worker node. - - Enable feature gate per :doc:`Prerequisites ` - * - :ref:`nvidia.com/cc.mode.state not matching nvidia.com/cc.mode ` - - Mode transition still in progress, or blocked by a workload using a GPU on the node. - - Wait 1-2 minutes, check cc.mode labels. If GPU Operator pods, specifically the vfio-manager are stuck in terminating, make sure that no user workloads are running on the node. - * - :ref:`nvidia.com/cc.mode.state is failed ` - - Workload running during mode change, or BIOS/ACS misconfigured. - - Drain workloads, re-apply mode label, confirm ACS enabled in BIOS. - -.. _coco-gpu-operator-logs: - -********************** -View GPU Operator Logs -********************** - -Use this section to collect GPU Operator pod logs when an operand is not running or reporting errors. - -#. Get the list of GPU Operator pods: - - .. code-block:: console - - $ kubectl get pods -n gpu-operator - - *Example Output:* - - .. code-block:: output - - NAME READY STATUS RESTARTS AGE - gpu-operator-1766001809-node-feature-discovery-gc-75776475sxzkp 1/1 Running 0 86s - gpu-operator-1766001809-node-feature-discovery-master-6869lxq2g 1/1 Running 0 86s - gpu-operator-1766001809-node-feature-discovery-worker-mh4cv 1/1 Running 0 86s - gpu-operator-f48fd66b-vtfrl 1/1 Running 0 86s - nvidia-cc-manager-7z74t 1/1 Running 0 61s - nvidia-kata-sandbox-device-plugin-daemonset-d5rvg 1/1 Running 0 30s - nvidia-sandbox-validator-6xnzc 1/1 Running 0 30s - nvidia-vfio-manager-h229x 1/1 Running 0 62s - -#. Get specific logs for a pod: - - .. code-block:: console - - $ kubectl logs -n gpu-operator - - Replace ```` with the name of the GPU Operator pod from ``kubectl get pods -n gpu-operator``. - Logs for ``nvidia-kata-sandbox-device-plugin-daemonset-``, ``nvidia-cc-manager-``, and ``nvidia-vfio-manager-`` can be most useful for troubleshooting Confidential Containers issues. - - -.. _coco-view-kata-logs: - -************************* -View Kata Containers Logs -************************* - -Use this section to collect Kata Containers logs and confirm runtime classes are installed. - -#. Confirm the expected runtime classes are registered: - - .. code-block:: console - - $ kubectl get runtimeclass - - After a successful Kata Containers deployment, you should see ``kata-qemu-nvidia-gpu-snp`` (AMD SEV-SNP) and ``kata-qemu-nvidia-gpu-tdx`` (Intel TDX) in the output. - If these are missing, continue to the next steps. - -#. Get the list of Kata Containers pod: - - .. code-block:: console - - $ kubectl get pods -n kata-system - - *Example Output:* - - .. code-block:: output - - NAME READY STATUS RESTARTS AGE - kata-deploy- 1/1 Running 0 6m37s - -#. View the logs for the Kata Containers pod: - - .. code-block:: console - - $ kubectl logs -n kata-system - - Replace ```` with the name of the Kata Containers pod. - - *Example Output:* - - .. code-block:: output - - Install completed - daemonset mode: waiting for SIGTERM - -If the logs show errors or runtime classes are still missing after a successful Helm deploy, collect the log output and refer to :ref:`Getting Help ` for Kata-specific troubleshooting resources. - - -.. _coco-cc-mode-troubleshoot: - -****************************************************************** -``nvidia.com/cc.mode.state`` Not Matching ``nvidia.com/cc.mode`` -****************************************************************** - -When changing the Confidential Computing mode (refer to :doc:`Managing the Confidential Computing Mode `), the Confidential Computing Manager updates the ``nvidia.com/cc.mode.state`` label to reflect the current state of the Confidential Computing mode. -If the ``nvidia.com/cc.mode.state`` does not match the desired CC mode (``on``, ``off``, or ``ppcie``), it could mean the following: - -* The GPU is still updating to the Confidential Computing mode. - Wait a few more minutes, then check the labels again. -* The transition is blocked by a user workload with a resource claim for a GPU on the node. - This is usually accompanied by the VFIO manager stuck in Terminating state or CC Manager logs showing the mode transition is still in progress. - Remove the workload to unblock the mode transition. - -**Checks:** - -Set the ``NODE_NAME`` environment variable to the node you want to check: - -.. code-block:: console - - $ export NODE_NAME="" - -#. Check the cc.mode labels: - - .. code-block:: console - - $ kubectl get node $NODE_NAME -o json | \ - jq '.metadata.labels | with_entries(select(.key | startswith("nvidia.com/cc")))' - - *Example Output:* - - .. code-block:: json - - { - "nvidia.com/cc.mode": "on", - "nvidia.com/cc.mode.state": "off", - "nvidia.com/cc.ready.state": "false" - } - -#. Get the list of GPU Operator pods: - - .. code-block:: console - - $ kubectl get pods -n gpu-operator - - *Example Output:* - - .. code-block:: output - - NAME READY STATUS RESTARTS AGE - gpu-operator-6474ddf79d-s4gcb 1/1 Running 0 10m - gpu-operator-node-feature-discovery-gc-8fb8d5d8d-mvvfz 1/1 Running 0 10m - gpu-operator-node-feature-discovery-master-5bbc6d887b-66wrs 1/1 Running 0 10m - gpu-operator-node-feature-discovery-worker-9xbb8 1/1 Running 0 10m - nvidia-cc-manager-tqdc6 1/1 Running 0 10m - nvidia-kata-sandbox-device-plugin-daemonset-b5tp7 1/1 Running 0 10m - nvidia-vfio-manager-b7jtv 0/1 Terminating 0 10m - -#. Get the logs for the nvidia-cc-manager pod: - - .. code-block:: console - - $ kubectl logs -n gpu-operator nvidia-cc-manager- - - Replace ```` with the name of the nvidia-cc-manager pod from ``kubectl get pods -n gpu-operator``. - - *Example Output:* - - .. code-block:: output - - 2026-06-18 19:47:26,095 - k8s-cc-manager - INFO - Resetting 2 GPU(s) to apply CC mode - 2026-06-18 19:47:26,095 - k8s-cc-manager - INFO - Resetting GPU 0000:0d:00.0 - 2026-06-18 19:47:26,475 - k8s-cc-manager - INFO - Resetting GPU 0000:b5:00.0 - - If the CC Manager logs show the mode transition is still in progress, it means the GPU is still updating to the Confidential Computing mode. - CC Manager logs show ``Successfully set CC mode to '' on all GPUs`` when the mode transition is complete. - -#. Check which pods have a passthrough GPU allocated on the node: - - .. code-block:: console - - $ kubectl get pods -A --field-selector spec.nodeName=$NODE_NAME -o json | \ - jq -r '.items[] | select(any(.spec.containers[]; .resources.requests["nvidia.com/pgpu"] // empty)) | "\(.metadata.namespace)/\(.metadata.name)"' - - *Example Output:* - - .. code-block:: output - - default/cuda-vectoradd-kata - - Any pods returned have a passthrough GPU allocated and are blocking the mode transition. - -#. Delete the pod(s) to unblock the mode transition. - - .. code-block:: console - - $ kubectl delete pod -n - - *Example Output:* - - .. code-block:: output - - pod "" deleted - - Repeat this step for each pod that is blocking the mode transition. - Once all user pods are deleted, the mode transition will resume automatically. - -#. Confirm the mode transition is complete: - - .. code-block:: console - - $ kubectl get pods -n gpu-operator - - *Example Output:* - - .. code-block:: output - - NAME READY STATUS RESTARTS AGE - gpu-operator-6474ddf79d-s4gcb 1/1 Running 0 10m - gpu-operator-node-feature-discovery-gc-8fb8d5d8d-mvvfz 1/1 Running 0 10m - gpu-operator-node-feature-discovery-master-5bbc6d887b-66wrs 1/1 Running 0 10m - gpu-operator-node-feature-discovery-worker-9xbb8 1/1 Running 0 10m - nvidia-cc-manager-tqdc6 1/1 Running 0 10m - nvidia-kata-sandbox-device-plugin-daemonset-b5tp7 1/1 Running 0 10m - nvidia-vfio-manager-b7jtv 1/1 Running 0 1m - - - -.. _coco-cc-mode-failed: - -****************************************** -``nvidia.com/cc.mode.state`` is ``failed`` -****************************************** - -When the ``nvidia.com/cc.mode.state`` is ``failed``, it means there was a problem updating the Confidential Computing mode on the GPU. -This typicall indicates that your GPU does not support Confidential Computing mode or there is a hardware error. -You may need to contact your :ref:`Hardware IT Administrator ` to confirm the GPU is supported and the hardware is functioning correctly. -Refer to the :doc:`Prerequisites ` for more information on required hardware. - -**Checks:** - -Set the ``NODE_NAME`` environment variable to the node you want to check: - -.. code-block:: console - - $ export NODE_NAME="" - -#. Confirm no user workloads are running on the node before changing CC mode. - List pods scheduled on the node: - - .. code-block:: console - - $ kubectl get pods -A --field-selector spec.nodeName=$NODE_NAME -o wide - - This lists pods on ``$NODE_NAME``. - ``kube-system`` DaemonSets (for example CNI or ``kube-proxy``) are expected on every worker node. - ``gpu-operator`` and ``kata-system`` pods are expected only if this node is configured for Confidential Containers (labeled ``nvidia.com/gpu.workload.config=vm-passthrough`` or cluster-wide ``sandboxWorkloads.defaultWorkload=vm-passthrough``). - Delete or reschedule any other ``Running`` pods (especially GPU workloads) before changing CC mode. - -#. View ``nvidia-cc-manager`` pod logs: - - .. code-block:: console - - $ kubectl logs -n gpu-operator nvidia-cc-manager- - - Replace ```` with the name of the ``nvidia-cc-manager`` pod from ``kubectl get pods -n gpu-operator``. - -#. Confirm hardware virtualization and ACS are enabled in the host BIOS. - One way to do this is to check for ``vmx`` (Intel) or ``svm`` (AMD) in ``/proc/cpuinfo``. - For ACS, coordinate with your :ref:`Hardware IT Administrator ` if needed. - -#. Re-apply the desired mode label to retry the transition: - - .. code-block:: console - - $ kubectl label node $NODE_NAME nvidia.com/cc.mode=on --overwrite - -#. Confirm the mode transition is complete by checking the CC mode labels: - - .. code-block:: console - - $ kubectl get node $NODE_NAME -o json | \ - jq '.metadata.labels | with_entries(select(.key | startswith("nvidia.com/cc")))' - - The ``nvidia.com/cc.mode.state`` label should match the desired mode when the transition is complete. - If the state is still ``failed``, refer to :ref:`Getting Help `. - -For mode configuration options, refer to :doc:`Managing the Confidential Computing Mode `. - -.. _coco-container-creating-cold-plug: - -************************************************************************* -Pod Stuck in ``ContainerCreating`` with ``device cold plug failed`` error -************************************************************************* - -If you see the following error when ``kubectl describe pod -n `` and the pod is stuck in the ``ContainerCreating`` state, it means the ``KubeletPodResourcesGet`` feature gate is not enabled on the worker node. -Refer to the Kubelet Configuration section in :doc:`Prerequisites ` for more information on setting the feature gate. - -.. code-block:: output - - Events: - Type Reason Age From Message - ---- ------ ---- ---- ------- - Warning FailedCreatePodSandBox 19s (x16 over 34s) kubelet (combined from similar events): Failed to create pod sandbox: rpc error: code = Unknown desc = failed to start sandbox "d0a43b5d3c6c433f011efbfacb6de3f7ac448f3d09a272cef8d43249712b12b1": failed to create containerd task: failed to create shim task: device cold plug failed: cold plug: GetPodResources failed for pod(cuda-vectoradd-kata) in namespace(default): rpc error: code = Unknown desc = PodResources API Get method disabled - -.. _coco-pending-pod: - -************************************************************************** -Pod Stuck in ``Pending`` State with ``Insufficient nvidia.com/pgpu`` Error -************************************************************************** - -If ``kubectl describe pod -n `` shows the pod stuck in the ``Pending`` state, the scheduler cannot place the pod on a node with available passthrough GPU capacity. - -.. code-block:: output - - Events: - Type Reason Age From Message - ---- ------ --- ---- ------- - Warning FailedScheduling ... default-scheduler 0/1 nodes are available: 1 Insufficient nvidia.com/pgpu. - -**Common causes:** - -* The worker node is not configured for Confidential Containers workloads. -* GPU Operator Confidential Containers operands are missing or not ``Running`` on the worker node. -* ``nvidia.com/pgpu`` capacity on the node is zero because GPUs are not bound to ``vfio-pci`` on the host. -* All passthrough GPUs on eligible nodes are already allocated to other pods. - -**Resolution:** - -Set the ``NODE_NAME`` environment variable to the affected node so you can copy-paste the commands below: - -.. code-block:: console - - $ export NODE_NAME="" - -#. Confirm GPU Operator operands are ``Running`` on the worker node: - - .. code-block:: console - - $ kubectl get pods -n gpu-operator -o wide --field-selector spec.nodeName=$NODE_NAME - - Expected Confidential Containers operands include ``nvidia-cc-manager``, ``nvidia-vfio-manager``, ``nvidia-kata-sandbox-device-plugin``, and ``nvidia-sandbox-validator``. - If an operand is not ``Running``, refer to :ref:`View GPU Operator Logs `. - -#. Confirm the node is configured for Confidential Containers workloads: - - .. code-block:: console - - $ kubectl describe node $NODE_NAME | grep nvidia.com/gpu.workload.config - - *Example Output:* - - .. code-block:: output - - nvidia.com/gpu.workload.config: vm-passthrough - - If the label is missing, add it: - - .. code-block:: console - - $ kubectl label node $NODE_NAME nvidia.com/gpu.workload.config=vm-passthrough - - If you set the cluster-wide default during installation instead of per-node labeling, confirm ``sandboxWorkloads.defaultWorkload`` is ``vm-passthrough``. - Refer to :ref:`Common GPU Operator Configuration Settings ` in :doc:`Detailed Install Guide `. - -#. Check ``nvidia.com/pgpu`` capacity on the node: - - .. code-block:: console - - $ kubectl describe node $NODE_NAME | grep nvidia.com/pgpu - - *Example Output:* - - .. code-block:: output - - nvidia.com/pgpu: 8 - nvidia.com/pgpu: 8 - - If capacity and allocatable are zero, GPUs are not available for scheduling. - On the worker host, confirm VFIO binding (``10de`` is the NVIDIA PCI vendor ID): - - .. code-block:: console - - $ lspci -nnk -d 10de: - - *Example Output (expected):* - - .. code-block:: output - - 65:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:xxxx] (rev a1) - Kernel driver in use: vfio-pci - - If the output shows ``Kernel driver in use: nvidia`` or ``nouveau``, remove host drivers as described in :ref:`Ensure No Host NVIDIA GPU Drivers Are Present `. - Confirm IOMMU is enabled: - - .. code-block:: console - - $ ls /sys/kernel/iommu_groups - - If the directory is empty or missing, configure IOMMU as described in :ref:`Prerequisites `, then reboot the host. - Review ``nvidia-vfio-manager`` pod logs on the affected node in :ref:`View GPU Operator Logs `. - After fixing host prerequisites, wait for operand pods to reconcile and confirm ``nvidia.com/pgpu`` is non-zero. - -#. If the node shows non-zero ``nvidia.com/pgpu`` capacity but the pod is still ``Pending``, all passthrough GPUs on eligible nodes may be allocated to other pods. - Check which pods currently have a passthrough GPU allocated: - - .. code-block:: console - - $ kubectl get pods -A --field-selector spec.nodeName=$NODE_NAME -o json | \ - jq -r '.items[] | select(any(.spec.containers[]; .resources.requests["nvidia.com/pgpu"] // empty)) | "\(.metadata.namespace)/\(.metadata.name)"' - - Wait for a workload to complete or free capacity before retrying. - -Refer to the optional VFIO validation step in :doc:`Detailed Install Guide `. - - -.. _coco-getting-help: - -************ -Getting Help -************ - -If the steps on this page do not resolve your issue, use the resources below based on which component is failing. - -NVIDIA GPU Operator and Confidential Computing Operands -======================================================= - -For issues with GPU Operator pods or Confidential Containers operands (``nvidia-cc-manager``, ``nvidia-vfio-manager``, ``nvidia-kata-sandbox-device-plugin``, and ``nvidia-sandbox-validator``): - -#. Review the :doc:`NVIDIA GPU Operator troubleshooting guide `. -#. If the issue is not documented there, run the GPU Operator ``must-gather`` utility to collect cluster diagnostics: - - .. code-block:: console - - $ curl -o must-gather.sh -L https://raw.githubusercontent.com/NVIDIA/gpu-operator/main/hack/must-gather.sh - $ chmod +x must-gather.sh - $ ./must-gather.sh - - The utility produces an archive with manifests and logs from GPU Operator-managed components. - -#. Prepare a bug report and file an issue in the `NVIDIA GPU Operator GitHub repository `_. - -Kata Containers -=============== - -For issues with ``kata-deploy``, missing runtime classes, or Kata runtime failures: - -#. Search the `Kata Containers GitHub issues `_ for similar reports. -#. If no existing issue matches your problem, `open a new issue `_ in that repository. - - Include your environment details, Kata chart version, ``kata-deploy`` pod logs, and cluster configuration. - -Attestation and Upstream Confidential Containers -================================================ - -For attestation, Trustee, sealed secrets, or other upstream Confidential Containers features, refer to the `Confidential Containers documentation `__ and the `Confidential Containers GitHub repository `_. - -For NVIDIA Confidential Computing licensing requirements, refer to :doc:`Licensing `. diff --git a/confidential-containers/versions1.json b/confidential-containers/versions1.json deleted file mode 100644 index b83e3f622..000000000 --- a/confidential-containers/versions1.json +++ /dev/null @@ -1,11 +0,0 @@ -[ - { - "preferred": "true", - "url": "../1.1.0/", - "version": "1.1.0" - }, - { - "url": "../1.0.0/", - "version": "1.0.0" - } -] diff --git a/repo.toml b/repo.toml index 9761da848..2752d317e 100644 --- a/repo.toml +++ b/repo.toml @@ -210,19 +210,6 @@ build_by_default = false output_format = "linkcheck" -[repo_docs.projects.confidential-containers] -docs_root = "${root}/confidential-containers" -project = "confidential-containers" -name = "NVIDIA Confidential Containers Architecture" -version = "1.1.0" -source_substitutions = { kata_version = "4.0.0", gpu_operator_version = "v26.3.1", gpu_operator_minor_version = "26.3", genpolicy_version = "4.1.0", nvrc_version = "v0.1.5", guest_nvidia_driver_version = "595.58.03", guest_kernel_version = "6.18.35", qemu_version = "11.0.1", trustee_version = "v0.21.0", guest_components_version = "v0.21.0", trustee_image_tag = "258ea4acb7b9bd865fce5c63a539f2120dba8298", kbs_client_tag = "sample_only-258ea4acb7b9bd865fce5c63a539f2120dba8298-x86_64", trustee_kbs_image_digest = "sha256:873a1e1704965d1325b70fdf31335cc8d9c95acab4f003b0f3ece675b3584dd8", trustee_as_image_digest = "sha256:5319dcb609ed1d61876491bb43be1e03838f29eab7cea5673c7979892dc8015a", trustee_rvps_image_digest = "sha256:185cdc6754e544de3068a4f9c25733d62e7e6cfb8464da9f2de2ac490573b509" } -copyright_start = 2020 - -[repo_docs.projects.confidential-containers.builds.linkcheck] -build_by_default = false -output_format = "linkcheck" - - [repo_docs.projects.openshift] docs_root = "${root}/openshift" project = "gpu-operator-openshift"