Confidential VM disk image, firmware, kernel, and initfs. Built for use with confidentialai/kettle.
261
Confidential.ai uses this image to run attested builds in the system at https://build.confidential.ai. Go there to try it out!
This repository hosts the images that the build service uses to create Confidential VMs, executing the build and attesting the results so the Kettle CLI can prove exactly which image was used to host the build.
Kettle builds and verifies attested builds, packages that include cryptographically signed SLSA provenance certifying the source, tools, and machine used to create the build.
Get just the good parts of reproducible builds: the security and assurance of signed and provable inputs, without the misery of constantly repairing your build system.
Attested builds allow anyone to verify the exact inputs that produced any binary output, by adding cryptographic signatures showing exactly what source code, dependencies, and toolchains were used.
Kettle uses TEEs (Trusted Execution Environments) to sign builds using hardware attestation. Hardware attestations are verified against certificates published by the hardware manufacturer, cryptographically linking binaries to their exact source code.
Kettle's attested builds provide a solution to almost every scenario where binaries need a verification trail directly back to the source code and tools that created them. This is just a few examples of problems Kettle can solve:
Most build systems can't provide hardware-secured build machines. Kettle ensures your build was created and signed inside a confidential virtual machine, with memory and compute secured even against a malicious hypervisor. In contrast, if you use GitHub's artifact attestations, you are forced to simply take GitHub's word that their cloud VMs didn't tamper with your build.
Using Kettle to build and attest inside a TEE gives you hardware-based cryptographic assertion, dramatically reducing the number of parties you are forced to trust. You only need to trust the hardware manufacturer and the physical custodians of your build machines. No need to trust the sysadmins with root on the bare metal, or the authors of the hypervisor that creates and manages your build VMs, or the developers maintaining the image your code will run on. The code that runs in your TEE is signed by the hardware, so you can be sure what ran, and encrypted so even the hypervisor can't read the memory of your job as it runs.
Run kettle verify to cryptographically verify your binaries. Kettle will read the evidence.json, verify the signature using hardware vendor public keys, and then validate the signed provenance.json and use it to confirm the checksum of your binary.

Verify the attested build created above like this:
kettle verify ripgrep/kettle-build
Two optional flags tie the attestation to the exact VM image that produced it:
--igvm <FILE> — verify that the attested launch measurement matches this IGVM
file's launch digest, proving the build ran in a confidential VM booted from
exactly this IGVM.--image <FILE> — verify that the dm-verity roothash committed inside the IGVM
matches the roothash stored in this disk image (disk.raw), binding the
verified IGVM to a specific root filesystem. Requires --igvm.kettle verify ripgrep/kettle-build --igvm guest.igvm --image disk.raw
Content type
Unrecognized
Digest
sha256:5e3ae66a9…
Size
2.2 GB
Last updated
3 months ago
docker pull confidentialai/kettle-server