Confidential compute

Supported Configurations

Running the control plane as a container with:

• Private Nodes

This page explains where vCluster fits in a confidential compute platform and shows the configuration patterns to connect it to a confidential runtime. vCluster has no confidential compute feature of its own. It provides tenant isolation and workload routing around the confidential runtime you deploy on the worker nodes. If your confidential compute stack runs on standard Kubernetes, it runs through vCluster.

For provider-specific instance settings, node image contents, attestation verification, and support boundaries, follow your provider and runtime documentation.

Confidential compute protects workload code and data in use by running it inside a hardware-backed trusted execution environment (TEE). Common examples are Intel TDX and AMD SEV-SNP. vCluster gives each tenant a dedicated Kubernetes control plane and routes workloads to confidential-capable nodes using standard Kubernetes mechanisms such as RuntimeClass, node selectors, and node labels. The TEE protects workload data on the worker nodes. Tenants get that hardware-level protection combined with Kubernetes-level isolation from other tenants through vCluster.

Where the TEE sits in the stack determines how you configure the node image and what tenants need to do to use it:

• Cloud-provider Confidential VMs (GCP Confidential VMs, Azure Confidential Computing, AWS EC2 instances with AMD SEV-SNP): the hypervisor applies hardware-backed protection to the entire VM. All workloads on the node run inside the TEE. Attestation usually runs at node bootstrap time, before the node joins the cluster. No RuntimeClass is required.
• Pod-level runtime (Kata Containers, Confidential Containers): each pod runs in a lightweight VM backed by a hardware TEE. Requires the runtime on the node image, a RuntimeClass object available to the tenant cluster, and a runtimeClassName in the pod spec. This approach works on any compatible bare metal or cloud VM.

The sections below apply to both paths unless noted.

Reference architecture

Use vCluster as the tenant Kubernetes layer. Add vMetal if the confidential-capable capacity comes from physical servers you manage, and add vNode if tenant workloads need stronger runtime isolation. Then install and operate the confidential compute runtime on the private nodes selected for confidential workloads.

Confidential compute architecture with vCluster, private nodes, optional vMetal and vNode, and separate Confidential VM and pod-level runtime paths

In this model, vCluster decides which tenant gets access to which Kubernetes environment. Auto nodes selects the right capacity, vMetal prepares and joins the machine, vNode strengthens the workload boundary, and the confidential runtime executes the workload in the hardware-backed environment. For the strongest isolation guarantee, assign private nodes to a single tenant cluster rather than sharing nodes across tenants.

The components in this architecture each cover a distinct layer:

• vCluster provides each tenant with an isolated Kubernetes control plane and a scheduling boundary for workloads.
• Private nodes give the tenant dedicated worker nodes for workloads that require dedicated compute.
• Auto nodes connect workload demand to node provisioning through vCluster Platform.
• vMetal (optional) provisions and recycles physical servers that have the required CPU, firmware, OS image, drivers, and runtime configuration.
• vNode (optional) adds a runtime isolation layer for privileged or untrusted workloads inside the tenant environment.
• A confidential runtime — either a cloud-provider Confidential VM or a pod-level runtime such as Kata Containers and Confidential Containers — provides the hardware-backed TEE and attestation.

Implementation checklist

1. Select hardware or cloud instance types that support the target confidential compute technology.
2. Configure provider-specific VM options, firmware, Shielded VM features (secure boot, vTPM, integrity monitoring), and host OS images.
3. Prepare the node image for your runtime path:
   • Cloud-provider VMs: enable Confidential VM features and configure bootstrap attestation.
   • Pod-level runtime: install Kata Containers, Confidential Containers, runtime classes, and attestation services.
4. Register the hardware in vMetal or another node provider.
5. Add node type properties that describe the confidential compute capability.
6. Configure privateNodes.autoNodes to select those node types.
7. Add vNode where tenant workloads need stronger runtime isolation.
8. Validate scheduling, attestation, and workload execution from inside the tenant cluster.

Build the capacity layer

Start by creating node types that represent confidential-capable hardware. Node type properties become selector requirements, so you can expose hardware features such as tdx, sev-snp, GPU model, firmware track, or image family to vCluster auto nodes.

NodeProvider — platform admin

apiVersion: management.loft.sh/v1
kind: NodeProvider
metadata:
  name: bare-metal
spec:
  # Use the Metal3 node provider when capacity comes from physical servers.
  metal3:
    clusterRef:
      cluster: datacenter
      namespace: metal3
    nodeTypes:
      - name: tdx-large
        resources:
          cpu: "64"
          memory: 512Gi
        bareMetalHosts:
          # Select only BareMetalHost resources prepared for TDX workloads.
          selector:
            matchLabels:
              confidential-compute: tdx
        # Expose confidential compute traits as node type properties.
        properties:
          confidential-compute: tdx

This node provider creates a tdx-large node type. Auto nodes can select this node type when a tenant cluster requests TDX-capable capacity.

If the confidential-capable capacity comes from physical servers, vMetal can register servers, provision the OS image, and join each server to the tenant cluster as a private node. Any node provider that can attach a prepared worker to the cluster works. vMetal is one option, not a requirement.

Prepare the OS image and bootstrap flow for the confidential runtime before offering the node type to tenants. This typically includes firmware settings, Shielded VM features (secure boot, vTPM, and integrity monitoring), kernel support, and the confidential runtime configuration for your chosen path.

Configure host maintenance behavior according to the provider and confidential compute technology. Some Confidential VM machine types support live migration, while others require stop-on-maintenance behavior such as on_host_maintenance: TERMINATE or the provider-specific equivalent. Confirm the supported maintenance policy for the selected instance type before publishing the node type.

Cloud-provider confidential node types also require an explicit zone, not just a region. Cloud providers enforce zone placement for Confidential VM instances.

Attestation

Cloud-provider VMs: attestation usually runs as a bootstrap gate before the node joins the cluster. The gate should request and verify provider or hardware attestation evidence against your policy before allowing the kubeadm join. Checking hardware markers such as /dev/sev-guest for SEV-SNP or /dev/tdx_guest for TDX is only a local sanity check. It does not replace quote or report verification. Depending on the provider and trust model, verification can be local, provider-managed, or performed by an external verifier.

Pod-level runtime: each pod generates an attestation quote at workload start time. The node image must include device plugins for quote generation, such as the Intel TDX attestation driver or AMD SEV-SNP device plugin, and the Data Center Attestation Primitives libraries your attestation service expects. The attestation service endpoint must be reachable from the private nodes. If your platform enforces network policies, add an egress rule that permits attestation traffic before publishing the node type to tenants.

Route workloads to confidential nodes

A platform admin configures the tenant cluster to use confidential nodes by requiring the confidential-capable node type property. vCluster Platform provisions matching nodes when the tenant cluster needs capacity.

vcluster.yaml — platform admin

privateNodes:
  # Enable dedicated worker nodes for this tenant cluster.
  enabled: true
  autoNodes:
    - provider: bare-metal
      dynamic:
        - name: confidential-workers
          # Require a node type that advertises TDX support.
          nodeTypeSelector:
            - property: confidential-compute
              operator: In
              values:
                - tdx

This configuration lets vCluster Platform provision matching private nodes when the tenant cluster needs confidential-capable worker capacity.

Private nodes join the tenant cluster as real nodes, so their OS-level labels are visible inside the cluster and the nodeSelector works without any additional configuration.

For the pod-level runtime path, tenants add a runtimeClassName referencing the RuntimeClass installed in the control plane cluster and exposed to the tenant cluster. RuntimeClass syncing is disabled by default, so the platform admin must sync the allowed RuntimeClass objects into the tenant cluster before tenants can reference them.

The next two examples apply only to the pod-level runtime path. If you use cloud-provider Confidential VMs, the private node selection above is the vCluster-specific configuration; finish the VM image, maintenance policy, and attestation setup in your provider tooling.

vcluster.yaml — platform admin (pod-level runtime path)

sync:
  fromHost:
    runtimeClasses:
      enabled: true
      selector:
        matchLabels:
          confidential-compute: tdx

privateNodes:
  enabled: true
  autoNodes:
    - provider: bare-metal
      dynamic:
        - name: confidential-workers
          nodeTypeSelector:
            - property: confidential-compute
              operator: In
              values:
                - tdx

Label the RuntimeClass in the control plane cluster so only approved runtime classes are synced:

RuntimeClass — control plane cluster

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: kata-qemu-tdx
  labels:
    confidential-compute: tdx
handler: kata-qemu-tdx

For the full selector and patches reference, see Runtime classes.

For cloud-provider Confidential VMs, omit runtimeClassName. Protection applies at the VM level and standard containers run inside the TEE without modification.

Pod spec — tenant (pod-level runtime path)

apiVersion: v1
kind: Pod
metadata:
  name: confidential-workload
spec:
  # Use the confidential runtime configured on the private node image.
  runtimeClassName: kata-qemu-tdx
  # Schedule only onto nodes that advertise TDX support.
  nodeSelector:
    confidential-compute: tdx
  containers:
    - name: app
      image: ghcr.io/example/confidential-app:1.0.0

This pod runs with the confidential RuntimeClass and schedules onto nodes that match the confidential compute property.

Add vNode for tenant isolation

vNode adds a runtime isolation layer for tenant workloads. It's useful when tenants need privileged workloads or host-like APIs without giving those workloads direct access to the underlying host.

For confidential compute builds, use vNode as an isolation layer around tenant workloads and pair it with the confidential RuntimeClass exposed on prepared private nodes. This is a useful pattern for platform teams that need both tenant isolation and hardware-backed workload execution.

Review the vNode architecture and vNode limitations while designing the runtime stack. vNode operates at the OS layer using Linux user namespaces, while Kata Containers operates at the VM layer. Their interaction depends on kernel version and node configuration. Validate vNode, Kata Containers, Confidential Containers, the node image, and the target hardware together before publishing the node type to tenant teams.

Learn more

For cloud-provider Confidential VMs, start with your provider's Confidential VM and attestation documentation to understand instance requirements, firmware options, and the bootstrap attestation flow.

For the pod-level runtime path, use these resources to plan the confidential runtime and attestation parts of the platform.

Resource	Use it for
Kata Containers	Pod-level virtualized container runtime
Kata Containers documentation	Runtime architecture and configuration
Confidential Containers	Kubernetes workloads that use hardware-backed trusted execution environments
Confidential Containers documentation	Operator, runtime, and attestation guidance