> This page is for Confidential Containers, version Dev. > For other versions, use one of these documentation indexes: > - v1.1.0 (default): https://docs.nvidia.com/confidential-computing/containers/v1.1.0/llms.txt > - v1.0.0: https://docs.nvidia.com/confidential-computing/containers/v1.0.0/llms.txt > - Dev: https://docs.nvidia.com/confidential-computing/containers/dev/llms.txt > For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.nvidia.com/confidential-computing/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.nvidia.com/confidential-computing/_mcp/server. # Attestation > As a Security Engineer, use this page to understand attestation concepts and stand up a local Trustee instance for testing. As a [Security Engineer](/confidential-computing/containers/dev/personas#coco-persona-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](https://confidentialcontainers.org/docs/attestation/) and the end-to-end [NVIDIA NIM Confidential GPU Attestation](https://confidentialcontainers.org/docs/examples/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 [Attach a Kata Agent Security Policy](/confidential-computing/containers/dev/configure-workloads#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](https://confidentialcontainers.org/docs/architecture/design-overview/) 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](https://confidentialcontainers.org/docs/attestation/) and the [NVIDIA NIM Confidential GPU Attestation](https://confidentialcontainers.org/docs/examples/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](https://docs.docker.com/engine/install/) 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](https://oras.land/docs/installation) 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 v0.21.0. The repository ships with a `docker-compose.yml` that wires KBS, the Attestation Service, and the Reference Value Provider Service together. ```console git clone --branch v0.21.0 --depth 1 https://github.com/confidential-containers/trustee.git && cd trustee ``` Start the Trustee containers in the background. ```console docker compose up -d ``` *Example Output:* ```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 v0.21.0 [docker-compose.yml](https://github.com/confidential-containers/trustee/blob/v0.21.0/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 v0.21.0. > 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:258ea4acb7b9bd865fce5c63a539f2120dba8298` > > * AS: `ghcr.io/confidential-containers/staged-images/coco-as-grpc:258ea4acb7b9bd865fce5c63a539f2120dba8298` > > * RVPS: `ghcr.io/confidential-containers/staged-images/rvps:258ea4acb7b9bd865fce5c63a539f2120dba8298` > > Those tags are the Trustee v0.21.0 commit, the same commit as the `kbs-client` artifact in the next step. > The GHCR registry does not publish a `v0.21.0` tag for these images. > Equivalent digest pins are `kbs-grpc-as@sha256:873a1e1704965d1325b70fdf31335cc8d9c95acab4f003b0f3ece675b3584dd8`, `coco-as-grpc@sha256:5319dcb609ed1d61876491bb43be1e03838f29eab7cea5673c7979892dc8015a`, and `rvps@sha256:185cdc6754e544de3068a4f9c25733d62e7e6cfb8464da9f2de2ac490573b509`. > 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. ### Step 2: Verify Trustee Is Running Confirm all three Trustee containers are up. ```console docker compose ps ``` *Example Output:* ```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. ```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 `v0.21.0` tag for this artifact. Pull the `sample_only` build for the Trustee v0.21.0 commit on `x86_64`. ```console oras pull ghcr.io/confidential-containers/staged-images/kbs-client:sample_only-258ea4acb7b9bd865fce5c63a539f2120dba8298-x86_64 ``` *Example Output:* ```output Downloading 5148271f5a55 kbs-client Downloaded 5148271f5a55 kbs-client Pulled [registry] ghcr.io/confidential-containers/staged-images/kbs-client:sample_only-258ea4acb7b9bd865fce5c63a539f2120dba8298-x86_64 Digest: sha256:429be62c527e766a9854f9dac37f878010069c4aa6745d3d555d2bf393b9e82e ``` Confirm the `kbs-client` binary was extracted to the current directory. ```console ls kbs-client ``` Make the binary executable. ```console chmod +x kbs-client ``` Confirm the binary runs. ```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](https://confidentialcontainers.org/docs/attestation/client-tool/). ### 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. ```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:* ```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](https://confidentialcontainers.org/docs/examples/nvidia-nim-confidential-gpu-attestation/): A complete example deploying Trustee, configuring attestation policies, and running a confidential NVIDIA NIM workload with GPU attestation. * [Attestation](https://confidentialcontainers.org/docs/attestation/): Trustee architecture, configuration, resources, policies, the client tool, and guidance for production deployment topology, network configuration, and hardening. * [Features](https://confidentialcontainers.org/docs/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: ```console docker compose down ```