What is Ratatouille?
Ratatouille (Remote ATtestation made practical) is a continuous TPM-backed attestation system for Linux machines with TPM 2.0.
It lets you prove, cryptographically and in real time, that every machine in your Linux fleet is running exactly the software you approved and has not been tampered with since enrollment. The critical distinction here is that the evidence Ratatouille produces is independently verifiable by any third party using open tooling.
You can think of it as a notarized audit trail for machine state, except the notary is the TPM hardware itself, so the only people you are trusting are the guys who manufactured your device. (you are already doing this when you use that device)
When an access-control system or an auditor asks âhow do you know your machines are running what theyâre supposed to?â the current answer is usually a form, a vendor dashboard, or a periodic scan. None of those are independently verifiable. The relying party has to trust whoever filled out the form or the vendor who ran the scan. Ratatouille replaces that with a cryptographic chain rooted in hardware that any third party can independently replay and verify, without trusting you or any vendor.
Building it yourself is harder. The pieces for hardware-rooted attestation exist â TPMs, RATS, Signature verification â but assembling them into an operational system means building TPM registration workflows, IMA policy generation and management, a RATS aligned verifier, a GitOps fan-out pipeline with signature verification, then maintaining all of it across your fleet. Most teams that need this capability donât have months to spend on the infrastructure layer.
Ratatouille operationalizes the full stack so you donât have to build it.
What it actually does
Section titled âWhat it actually doesâRatatouille targets Linux machines with TPM 2.0: physical servers, cloud VMs with vTPMs (AWS NitroTPM, GCP Shielded VM, Azure Trusted Launch), and Linux IoT/edge devices.
The Ratatouille flow breakdown is as follows: You (the user) designates a Git repository to store runtime policies and their history. When you run rat init-baseline, Ratatouille captures the IMA log from your baseline machine and generates a Keylime allowlist. The Keylime allowlist is the set of file hashes permitted to appear in future IMA log entries. You sign that policy with Cosign and push it to the repository. The signature is recorded in the Rekor transparency log at the same time, creating a permanent, attributable record of who approved this policy and when.
Every push to the repository is ingested by Ratatouilleâs webhook, which verifies the Cosign signature and distributes the new policy to the Keylime verifier for every device enrolled in the associated policy group. From that point on, every TPM quote and IMA log segment is evaluated against the updated policy.
What trust verdicts enable. A TRUSTED result can gate audit evidence export, access control decisions, SPIFFE/SPIRE workload identity issuance, and secret provisioning. An UNTRUSTED result can execute revocation actions, shut down devices, or flag for investigation.
Built on open standards
Section titled âBuilt on open standardsâRatatouille does not introduce a proprietary trust model. It operationalizes proven open-source components:
- Keylime â TPM-based remote attestation and IMA log verification. CNCF Sandbox project, shipped in RHEL 9 and SLE Micro. Ratatouille is the operational layer; Keylime is the engine.
- Sigstore / Cosign â Keyless code signing and policy verification. Every policy approval is attributable to a specific authenticated identity and permanently auditable.
- IMA (Linux Integrity Measurement Architecture) â Kernel-level measurement of every executed binary. The OS cannot alter what IMA recorded.
- IETF RATS (RFC 9334) â The standards framework defining Attester, Verifier, and Relying Party roles. Ratatouille is aligned with the RATS background-check model, scoped to Linux with TPM 2.0.
You own the policies, the evidence, and the cryptographic chain. No lock-in. If Ratatouille disappears tomorrow, your evidence and policies remain valid and verifiable.
What Ratatouille is not
Section titled âWhat Ratatouille is notâNot a general-purpose attestation platform. Ratatouille covers Linux machines with TPM 2.0. It does not cover macOS, Windows, GPU firmware, NIC firmware, or BMC. If you need heterogeneous hardware attestation, thatâs a different product.
Not a compliance dashboard. Vanta tells you your policies are set correctly. Ratatouille tells you your machines are running what you think theyâre running. These are different layers â and increasingly, regulations require both.
Not infinite-scale out of the box. Every machine type with different software stacks needs its own IMA runtime policy. Every package update across every machine type requires policy regeneration. Policy lifecycle management is the current operational challenge.
What the baseline actually covers. The TPM quote covers PCR 7 (UEFI Secure Boot state), which proves whether Secure Boot was enabled at boot and whether the boot chain matched a known-good state. IMA picks up after the kernel loads and its measurement policy activates, extending a hash into PCR 10 for every executable, kernel module, and shared library that runs. The Keylime allowlist covers both: it validates PCR 7 against the expected Secure Boot state and checks every IMA log entry against the set of hashes captured at baseline time.
The baseline limitation. The allowlist is a snapshot of what ran on a specific machine between boot and the moment rat init-baseline was run. Any binary that had not yet executed at baseline time will cause an attestation failure the first time it runs â it appears in the IMA log but is absent from the allowlist.
In practice, baseline capture should happen after the machine has fully settled: all expected daemons started, maintenance scripts run, and any binaries that would run during normal operation exercised at least once. This makes Ratatouille well-suited for immutable or appliance-style deployments (IoT devices, fixed-image VMs, purpose-built servers) where the software set is stable and bounded. For general-purpose servers that receive regular package updates, the baseline must be regenerated and re-signed after each update.
Next steps
Section titled âNext stepsâThe Remote Attestation Primer covers the underlying concepts (TPMs, IMA, and the RATS framework) for readers who want to understand the mechanics. To get a machine enrolled, start with the Quickstart Guide. To see the full flow live, including a triggered attestation failure, go to the Live Demo.