Sign inSign up

confidentialai/kettle-server

By confidentialai

•Updated 3 months ago

Confidential VM disk image, firmware, kernel, and initfs. Built for use with confidentialai/kettle.

Artifact
0

261

confidentialai/kettle-server repository overview

⁠Kettle Server, for attested builds

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.

⁠Attested builds

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.

⁠Why attested builds?

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.

⁠Use cases for attested builds

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:

  • A customer deploying your service wants to know it’s running the code you claim, built from the source they audited.
  • A compliance team wants evidence that a binary was built with specific dependency versions, not newer ones with unknown changes.
  • A security auditor wants to verify that the toolchain used to compile a release matches the one specified in your security documentation.
  • A regulated enterprise wants proof that sensitive data will be processed only by code that passed their review, not by a modified version.
  • A package consumer wants to ensure that the binary they downloaded corresponds to the source code and dependencies they reviewed, not a tampered version.

⁠Why attest with Kettle?

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.

⁠Verify attested builds

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 hardware-signed evidence, which provides the checksums for the provenance and binary, which you can use to prove which source code, dependencies, and toolchain were used

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

Tag summary

Content type

Unrecognized

Digest

sha256:5e3ae66a9…

Size

2.2 GB

Last updated

3 months ago

docker pull confidentialai/kettle-server