Appendix A. Validated Configuration Profile Template#

Table 9: Validated Configuration Profile Template

Layer

Field

Deployed configuration

Evidence / owner

Server platform

OEM model, motherboard/platform, rack profile

(confirm from hardware BOM: server model, BIOS version, BMC firmware, rack profile)

OEM/integrator validation report

CPU TEE

CPU model, TEE mode, firmware/microcode, BIOS settings

(confirm: CPU SKU; SEV-SNP or TDX mode; firmware version from dmesg | grep -i snp or TDX equivalent; BIOS label names from OEM platform guide)

OEM/integrator with platform security owner

GPU confidential computing

GPU SKU/form factor/count, firmware, CC mode, topology

(confirm: GPU SKU and count; firmware from nvidia-smi -q | grep "Firmware Version"; CC mode from nvidia-smi conf-compute -q; all GPUs on node must be in CC mode) — MIG not supported; vGPU not supported

NVIDIA and OEM/integrator

Kubernetes platform

K8s distribution/version, node pool label, RuntimeClass, network policy

(confirm: K8s distribution and version; node pool label nvidia.com/cc.mode=on or ppcie; RuntimeClass from kubectl get runtimeclass; NetworkPolicy manifest)

Platform operator and CC software provider

Confidential containers runtime

Kata version, guest image digest, agent policy, AA, CDH

Kata Containers 3.29; Kata Lifecycle Manager 0.1.4; distroless guest OS; guest kernel 6.18.5; OVMF edk2-stable202511; QEMU 10.1 + Patches; genpolicy Rego annotation (confirm: guest image SHA256 digest — must be registered in RVPS before production key release)

CC software provider and platform operator

NVIDIA software

GPU Operator version, driver, device plugin, CC mode node labels

GPU Operator v26.3.1+; containerd 2.2.2+; NVIDIA driver inside UVM only — host has no NVIDIA driver; nvidia.com/cc.mode=on; nvidia.com/cc.ready.state=true (confirm: GPU Operator version from kubectl get pod -n gpu-operator; driver version from nvidia-smi inside a running UVM)

NVIDIA and platform operator

Key release

KBS/AS versions, topology, policy, KMS/HSM, collateral source, reference values

KBS protocol v0.4.0; OPA/Rego affirming policy (CPU TCB + GPU RIM); RVPS pre-loaded with CPU platform measurements (confirm: Trustee version; in-cluster vs. external topology; KMS backend; Helm values SHA in version control) — Note: Trustee HA and external KMS are operator configuration choices not covered by the GA release

CC software provider and key-release authority

Workload image/runtime

Image digest/signature, model artifact encryption, runtime policy, admin paths

OCI image signed with cosign; encrypted model layers via ocicrypt; guest-side image pull via nydus-snapshotter proxy mode; genpolicy Rego annotation; no SSH, no exec, no root shell (confirm: image SHA256 digest)

Model provider and application owner

Network/storage

Ingress, egress, collateral cache, SIEM

Inbound HTTPS/443 from approved gateway; outbound HTTPS/443 to KBS, OCI registry, NVIDIA collateral endpoint (or local cache); SIEM receives KBS JSON attestation logs — no payload data (confirm: collateral endpoint reachability or cache path; SIEM target)

Platform operator and security team

Validation scope

Positive/negative tests, benchmark, lifecycle

Positive: pod attests; KBS releases test key; inference serves requests. Negative: modified guest image digest, GPU not in CC mode, expired collateral, wrong RuntimeClass, kubectl exec — all must fail closed. Benchmark: pod-schedule-to-ready, attestation + key-release latency, LLM first-token latency. Lifecycle: Kata upgrade via Lifecycle Manager 0.1.4; model key rotation (confirm: test results captured and retained)

OEM/integrator and solution architects