coco docs: improvements for version pinning and minor fixes

confidential-containers/attestation.rst

@@ -114,12 +114,12 @@ Step 1: Install Trustee with Docker Compose
 -------------------------------------------
 
 Installing Trustee with Docker Compose is the recommended install path.
-Clone the upstream Trustee repository.
+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 https://github.com/confidential-containers/trustee.git && cd trustee
+   $ git clone --branch ${trustee_version} --depth 1 https://github.com/confidential-containers/trustee.git && cd trustee
 
 Start the Trustee containers in the background.
 
@@ -142,6 +142,22 @@ Start the Trustee containers in the background.
    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 <https://github.com/confidential-containers/trustee/blob/${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 <https://confidentialcontainers.org/docs/attestation/installation/docker/>`_ guide.
 
 
@@ -184,21 +200,21 @@ 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.
-
-Pull the ``kbs-client`` artifact into the current directory with ORAS.
+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:latest
+   $ oras pull ghcr.io/confidential-containers/staged-images/kbs-client:${kbs_client_tag}
 
 *Example Output:*
 
 .. code-block:: output
 
-   ✓ Pulled      kbs-client                                    12.3/12.3 MB 100.00%
-   ✓ Pulled      application/vnd.oci.image.manifest.v1+json    533/533  B  100.00%
-   Pulled [registry] ghcr.io/confidential-containers/staged-images/kbs-client:latest
-   Digest: sha256:a2a48a7cea6dc5d1bad3baea15f4162835e1262eb74fdf4847a6382d09dc5caa
+   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.
 

confidential-containers/confidential-containers-deploy.rst

@@ -165,6 +165,7 @@ The minimum required version is ${kata_version}.
       $ 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:*
@@ -200,8 +201,8 @@ The minimum required version is ${kata_version}.
 
    .. note::
 
-      Both ``kata-deploy`` and the GPU Operator deploy Node Feature Discovery (NFD) by default.
-      The install command includes ``--set nfd.enabled=false`` to prevent ``kata-deploy`` from deploying NFD.
+      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:

confidential-containers/configure-workloads.rst

@@ -335,11 +335,14 @@ 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 <coco-supported-software-components>` for the component matrix.
 
-#. Download ``genpolicy`` from the latest Kata Containers release that is compatible with this
-   reference architecture.
+#. Download ``genpolicy`` ${genpolicy_version} from the
+   `Kata Containers ${genpolicy_version} release <https://github.com/kata-containers/kata-containers/releases/tag/${genpolicy_version}>`_.
    For usage details, refer to the
-   `Agent Policy generation tool <https://github.com/kata-containers/kata-containers/blob/main/src/tools/genpolicy/README.md>`_
+   `Agent Policy generation tool <https://github.com/kata-containers/kata-containers/blob/${genpolicy_version}/src/tools/genpolicy/README.md>`_
    documentation.
 
 #. Run ``genpolicy`` against the manifest to deploy:

confidential-containers/install-quickstart.rst

@@ -169,7 +169,7 @@ Install the NVIDIA GPU Operator
          --set sandboxWorkloads.mode=kata \
          --set nfd.enabled=true \
          --set nfd.nodefeaturerules=true \
-         --version=v26.3.1
+         --version=${gpu_operator_version}
 
    *Example Output:*
 

confidential-containers/release-notes.rst

@@ -64,6 +64,22 @@ Changes include:
 
 * 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 <coco-supported-platforms>`.
+* Documented attaching a Kata agent security policy for attested production workloads.
+  Refer to :ref:`Attach a Kata Agent Security Policy <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 <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:

confidential-containers/samples/kata-nvidia-gpu-values.yaml

@@ -7,11 +7,11 @@ debug: false
 deploymentMode: daemonset
 
 # Disable Node Feature Discovery (NFD) deployment by kata-deploy.
-# Both kata-deploy and the GPU Operator deploy NFD by default. This
-# reference architecture relies on the NFD instance that the GPU Operator
-# deploys and manages, so the kata-deploy NFD is turned off to avoid a
+# Both kata-deploy and the GPU Operator can deploy NFD. This reference
+# architecture relies on the NFD instance that the GPU Operator deploys
+# and manages, so the kata-deploy NFD subchart is turned off to avoid a
 # duplicate, conflicting deployment.
-nfd:
+node-feature-discovery:
   enabled: false
 
 # Install the nydus snapshotter on each node alongside containerd.

confidential-containers/supported-platforms.rst

@@ -154,13 +154,15 @@ You do not supply or install these artifacts individually.
    * - Artifact
      - Release/Version
    * - Guest OS
-     - Distroless
+     - Distroless, with `NVRC ${nvrc_version} <https://github.com/NVIDIA/nvrc/releases/tag/${nvrc_version}>`__,
+       NVIDIA GPU driver ${guest_nvidia_driver_version}, and
+       `guest-components ${guest_components_version} <https://github.com/confidential-containers/guest-components/releases/tag/${guest_components_version}>`__ artifacts.
    * - Guest kernel
-     - 6.18.5
+     - ${guest_kernel_version}
    * - `OVMF <https://github.com/tianocore/edk2>`__
      - edk2-stable202511
    * - `QEMU <https://www.qemu.org/>`__
-     - 10.1 \+ Patches
+     - ${qemu_version} \+ Patches
 
 Separately Deployed Components and Interfaces
 =============================================
@@ -174,18 +176,20 @@ The following components and interfaces are not installed by the :doc:`Quickstar
      - Version
      - When It Is Needed
      - How It Is Provided
-   * - `Key Broker Service (KBS) protocol <https://confidentialcontainers.org/docs/attestation/>`__
-     - 0.4.0
-     - Required for Trustee-based attestation and secret or key release.
-     - The :doc:`Attestation <attestation>` quickstart installs a local evaluation Trustee.
+   * - `Trustee <https://github.com/confidential-containers/trustee/releases/tag/${trustee_version}>`__
+     - ${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 <attestation>` quickstart installs a local evaluation Trustee ${trustee_version}.
        Deploy a production Trustee separately by following the upstream Confidential Containers documentation.
    * - `Kata Lifecycle Manager <https://github.com/kata-containers/lifecycle-manager>`__
      - 0.1.8
      - Optional for Kata Containers upgrades and day-two lifecycle management.
      - Install separately by following the upstream Kata Lifecycle Manager documentation.
-   * - `Kata Containers genpolicy <https://github.com/kata-containers/kata-containers/blob/${kata_version}/src/tools/genpolicy/README.md>`__
-     - ${kata_version}
+   * - `Kata Containers genpolicy <https://github.com/kata-containers/kata-containers/blob/${genpolicy_version}/src/tools/genpolicy/README.md>`__
+     - ${genpolicy_version}
      - Used to generate an agent security policy for attested production workloads.
-     - Download separately from the corresponding Kata Containers release.
+       Refer to :ref:`Attach a Kata Agent Security Policy <kata-agent-security-policy>`.
+     - Download ``genpolicy`` ${genpolicy_version} from the `Kata Containers ${genpolicy_version} release <https://github.com/kata-containers/kata-containers/releases/tag/${genpolicy_version}>`__.
 
 Users may leverage `Red Hat OpenShift Sandboxed Containers <https://docs.redhat.com/en/documentation/openshift_sandboxed_containers/1.13>`__ to deploy Confidential Containers.

gpu-operator/deploy-kata-containers.rst

@@ -321,7 +321,7 @@ The minimum required version is ${kata_version}.
 
       $ helm install kata-deploy "${CHART}" \
          --namespace kata-system --create-namespace \
-         --set nfd.enabled=false \
+         --set node-feature-discovery.enabled=false \
          -f kata-nvidia-gpu-values.yaml \
          --version "${VERSION}"
 
@@ -341,8 +341,8 @@ The minimum required version is ${kata_version}.
 
    .. note::
 
-      Both ``kata-deploy`` and the GPU Operator deploy Node Feature Discovery (NFD) by default.
-      The install command includes ``--set nfd.enabled=false`` to prevent ``kata-deploy`` from deploying NFD.
+      Both ``kata-deploy`` and the GPU Operator can deploy Node Feature Discovery (NFD).
+      The install command disables the NFD deployment by ``kata-deploy``.
       The GPU Operator will deploy and manage NFD in the next step.
 
    .. note::

gpu-operator/release-notes.rst

@@ -204,6 +204,8 @@ Post-Release Documentation Updates
 * Added support for Kubernetes 1.36 for Canonical MicroK8s to the :ref:`bare-metal` table.
 * Added a brief explanation of the ``partitionN`` attribute to the :ref:`gpu-operator-kubevirt-dra` page.
 * Added support for Kubernetes 1.37 to the :ref:`bare-metal`, :ref:`cloud service providers <cloud-service-providers>`, and KubeVirt and OpenShift Virtualization tables.
+* Corrected the ``kata-deploy`` Helm install on the :doc:`Kata Containers with GPU Operator <deploy-kata-containers>` page.
+  The previous ``--set`` used a GPU Operator chart key that the ``kata-deploy`` chart ignores.
 
 
 ----

repo.toml

@@ -215,7 +215,7 @@ 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" }
+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]