Deploying a confidential worker

Cannabis workers must prove which protected environment will receive a job's keys. Selecting a VM advertised as confidential is the beginning of provider integration. Admission also requires a measured boot chain, the approved runtime, protected storage and the exact initialization policy expected by the requester.

The current client integrates Trustee CPU appraisals for SNP and TDX. No provider deployment has yet completed the protected execution and settlement acceptance checks. CUDA, ROCm and other accelerators remain part of the network's scope; each device and interconnect path requires its own evidence.

What the existing adapter expects

Both profiles also bind fresh challenge data, the guest-generated channel key and the approved job assignment. The current policy rejects an all-zero initialization digest. Do not change these fields or omit checks merely to make a provider's sample quote pass.

These bindings follow the pinned guest-components SNP adapter, TDX adapter, and Trustee verifier. The measured guest must consume and enforce that configuration; a matching digest supplied by an operator does not establish that the configuration was enforced.

Check provider compatibility before provisioning

For the existing profiles, the deployment route must provide the launch fields above and a way to reproduce the expected firmware, kernel, initialization and runtime measurements. Obtain that evidence before treating an instance as an admitted worker.

Google Cloud illustrates why the details matter. Its documented Compute v1 confidentialInstanceConfig exposes the technology choice and enable flag. The inspected schema has no HOST_DATA or MRCONFIGID setter. This is a compatibility gap to resolve, not proof that every provider mechanism is incapable of supplying those fields. A standard confidential-instance creation request is not established as compatible with this adapter. Compute API reference

Google distinguishes SNP hardware launch measurements from subsequent bootloader, kernel and userspace measurements held in its managed vTPM. Its TDX path records the boot chain in hardware measurement registers. Do not substitute a firmware-only measurement for evidence of the loaded Cannabis runtime. Attestation architecture

A provider-specific measured-boot profile can be added after its trust boundary, evidence format and enforcement are reviewed. Alternatively, a compatible bare-metal SNP/TDX deployment can expose the required launch controls. Neither route is authorized by an instance label or a runtime discovery report.

Distributed and accelerator work

Validate every rank, replacement, device and communication path. Google currently documents that its confidential GPU VMs do not support multi-node clusters, so that offering alone cannot establish Cannabis's distributed GPU training capability. Another supported deployment route and encrypted collective networking remain necessary. Supported configurations

Complete the worker acceptance run

Use the hardware-validation milestone to record the measured guest, requester-controlled verifier, disposable job-key delivery, protected workload execution, enforced resource limits and requester-decrypted result. Verify rejection of changed measurements and assignments, debug access, replay, unprotected storage and unsupported devices. Keep raw hardware identifiers and secrets private.

The guest evidence-service build, boot-image assembly, assignment initialization, guest session and workload preparation implement parts of this path. The boot-image entry point checks components and powers off without admitting workloads. Building or booting these components does not establish a measured confidential VM, and workload preparation does not launch a program. A provider is operational only after the protected launcher, transport and end-to-end payment and recovery behavior have been demonstrated and reviewed.

The guest resource boundary enforces kernel CPU, memory and process limits. Its independent guardian terminates job trees after supervisor death or a stopped supervisor's deadline, including detached descendants and a leaked control socket. Both run actual process checks in the boot image. The isolated runtime must additionally protect the control plane, storage, devices and network, enforce loaded-adapter policy and dispose of the guest on fatal failure. Resource counters alone do not establish execution privacy or payment acceptance.