> For the complete documentation index, see [llms.txt](https://docs.ionos.com/cloud/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ionos.com/cloud/compute-services/compute-engine/confidential-computing-vm/api-how-tos/attest-confidential-vm.md).

# Attest a Confidential VM

Cryptographically verify that your IONOS CLOUD Confidential VM runs an unmodified software stack on genuine AMD SEV-SNP hardware.

Attestation cryptographically proves that your Confidential VM is running an unmodified software stack on genuine AMD SEV-SNP hardware, with the expected security policy active. This topic explains how attestation works, when to use it, and how to set it up using either the <code class="expression">space.vars.ionos\_cloud</code> open-source reference toolchain (Example: [<mark style="color:blue;">SNPGuard</mark>](https://github.com/ionos-cloud/snp-guard)) or your own [<mark style="color:blue;">attestation service</mark>](https://docs.ionos.com/cloud/support/general-information/glossary-of-terms#attestation-service). It also covers re-attestation after software updates and the connectivity requirements your attestation service must meet.

{% hint style="info" %}
**Prerequisites:**

* Your Confidential VM image is prepared.
* Access to either [<mark style="color:blue;">SNPGuard</mark>](https://github.com/ionos-cloud/snp-guard) or your own attestation service implementation.
* Network connectivity planned from the VM to your attestation service.
  {% endhint %}

## How Confidential VM attestation works

{% stepper %}
{% step %}

### Understand how attestation works

Attestation is the mechanism by which a Confidential VM proves to your key server that it is running an unmodified software stack on genuine AMD hardware within a [<mark style="color:blue;">Trusted Execution Environment (TEE)</mark>](https://docs.ionos.com/cloud/support/general-information/glossary-of-terms#trusted-execution-environment-tee). The proof requires no trust in the network, the host, or <code class="expression">space.vars.ionos\_cloud</code>.

The protocol runs entirely within the `initrd`, before the operating system mounts the root filesystem. If the proof succeeds, the attestation service releases the [<mark style="color:blue;">Volume Master Key (VMK)</mark>](https://docs.ionos.com/cloud/support/general-information/glossary-of-terms#volume-master-key-vmk) and the VM boots. If anything in the startup chain has been tampered with or if the hardware cannot be verified, the proof fails and the VM halts.

1\. At every VM start, the AMD hardware generates a signed report containing:

* A [<mark style="color:blue;">measurement</mark>](https://docs.ionos.com/cloud/support/general-information/glossary-of-terms#measurement) (`SHA-384` hash) of the firmware, kernel, `initrd`, and kernel command line.
* The CPU security policy in effect
* The AMD hardware version

2\. Your attestation service receives this report, checks it against your registered expected values, and (if everything matches) releases your Volume Master Key, which unlocks the [<mark style="color:blue;">LUKS</mark>](https://docs.ionos.com/cloud/support/general-information/glossary-of-terms#linux-unified-key-setup-luks) root filesystem. If the check fails, the key is not released and the VM does not start into a trusted state.

{% hint style="info" %}
**Note:**

* **You do not need attestation to run a Confidential VM:** Your VM starts, your encrypted disk becomes available, and your workload runs without an attestation service.
* **Use attestation for verification:** Cryptographically prove that your VM runs exactly the software stack you built, on real AMD hardware, with the expected security policy active. If you need that guarantee (for compliance, key release policies, or your own trust model), deploy an attestation service.
  {% endhint %}
  {% endstep %}

{% step %}

### Understand why external verification is needed

In a zero-trust setting, encrypting RAM is not enough; you must also prove that the VM's startup process was not tampered with before it started. Software running within the VM cannot provide this proof on its own, as it is part of what needs to be verified.

1\. The AMD hardware generates a signed [<mark style="color:blue;">attestation report</mark>](https://docs.ionos.com/cloud/support/general-information/glossary-of-terms#attestation-report) from within the VM, one that cannot be forged by software.

2\. An external service you control then validates that report before releasing any secrets. <code class="expression">space.vars.ionos\_cloud</code> cannot operate this service on your behalf; if it did, it holds the key release decision, undermining the zero-trust model entirely.

3\. The CPU generates a **signed attestation report** containing the launch measurement.

4\. Your attestation service checks the following requirements:

* Is the attestation report signed by a genuine AMD CPU?
* Does the measurement match the expectation?

Only if both hold does it release the key that unlocks the disk.
{% endstep %}

{% step %}

### Plan connectivity requirements

Your attestation service must be reachable from the VM's network during the `initrd` launch phase, before any VPN or overlay network is established. Plan and validate this connectivity at image build time. If the attestation service is unreachable at startup, the VM cannot obtain the key and will not complete startup.
{% endstep %}

{% step %}

### Choose your attestation toolchain

{% tabs %}
{% tab title="SNPGuard IONOS CLOUD reference toolchain" %}
[<mark style="color:blue;">SNPGuard</mark>](https://github.com/ionos-cloud/snp-guard) is the <code class="expression">space.vars.ionos\_cloud</code> open-source reference implementation. It provides:

* An attestation client that runs within the VM's `initrd` at [<mark style="color:blue;">VMPL0</mark>](https://docs.ionos.com/cloud/support/general-information/glossary-of-terms#vm-privilege-level-0-vmpl0) (the highest hardware privilege level, required for valid attestation reports).
* A reference attestation service implementation.
* Image preparation tooling that automates LUKS encryption, client injection, measurement registration, and artifact embedding.

For more information, refer to the following:

* [<mark style="color:blue;">Repository</mark>](https://github.com/ionos-cloud/snp-guard)
* [<mark style="color:blue;">README</mark>](https://github.com/ionos-cloud/snp-guard/blob/main/README.md)
* [<mark style="color:blue;">Architecture</mark>](https://github.com/ionos-cloud/snp-guard/blob/main/docs/architecture.md)
  {% endtab %}

{% tab title="Own or partner tooling" %}
If you have an existing attestation service or prefer a commercial solution (for example, from an ISV partner), you can integrate directly with the AMD SEV-SNP attestation protocol. Your attestation client must:

* Run at `VMPL0` within the `initrd`, before the OS mounts the root filesystem.
* Request an attestation report from the AMD hardware.
* Send the report to your attestation service for verification.

For more information, refer to the [<mark style="color:blue;">AMD SEV-SNP Attestation specification</mark>](https://www.amd.com/en/developer/sev.html).
{% endtab %}
{% endtabs %}
{% endstep %}

{% step %}

### Understand re-attestation

If you update the kernel or `initrd` within a running VM, the measurement changes. The attestation service will reject the old measurement on the next start. You have two options:

1. **Register the new measurement** with your attestation service before rebooting. This is the standard update path.
2. **Re-attest from within the running VM:** SNPGuard provides an `attest renew` flow: the already-trusted VM submits its updated artifacts to the service, which registers them for the next start. This avoids a full rebuild-and-reupload cycle.

{% hint style="warning" %}
**Important:** Restarting a Confidential VM initiates a full stop-and-start rather than an in-place restart. For more information, see [<mark style="color:blue;">Limitations</mark>](/cloud/compute-services/compute-engine/confidential-computing-vm/overview/limitations.md). The attestation flow runs fresh on every start.
{% endhint %}
{% endstep %}
{% endstepper %}

{% hint style="success" %}
**Result:** Your Confidential VM attestation setup is complete. Your attestation service can now verify VM integrity and release keys on demand.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.ionos.com/cloud/compute-services/compute-engine/confidential-computing-vm/api-how-tos/attest-confidential-vm.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.