> 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/overview/security-and-trust-model.md).

# Security and Trust Model

Security model includes hardware-enforced operator exclusion, startup integrity, and key management

<code class="expression">space.vars.ionos\_cloud</code> Confidential VM enforces data privacy through hardware-level cryptography rather than software-based hypervisor controls. It details the zero-trust architecture, the four-step secure startup process, key management, shared responsibilities, and the boundaries of what Confidential VM protects.

## The zero-trust principle

Standard cloud environments rely on contractual assurances and internal access controls to protect VM data. These are policy-based guarantees: they depend on the provider behaving as agreed.

<code class="expression">space.vars.ionos\_cloud</code> Confidential VM replaces policy-based trust with a hardware-enforced cryptographic boundary. The AMD CPU architecture prevents access to VM memory, regardless of administrative privilege.

[<mark style="color:blue;">AMD SEV-SNP</mark>](https://docs.ionos.com/cloud/support/general-information/glossary-of-terms#amd-secure-encrypted-virtualization-with-secure-nested-paging-amd-sev-snp) encrypts VM memory using keys that the AMD Secure Processor, a dedicated security microcontroller embedded in the CPU, generates and holds. These keys never leave the silicon. The hardware's design physically excludes the hypervisor, the host operating system, <code class="expression">space.vars.ionos\_cloud</code> administrators, and <code class="expression">space.vars.ionos\_cloud</code> itself from the decryption path. <code class="expression">space.vars.ionos\_cloud</code> has no keys, no backdoor, and no mechanism to access your VM's memory.

For more information about what <code class="expression">space.vars.ionos\_cloud</code> does not cover, see [<mark style="color:blue;">Security boundaries (End-users' responsibility)</mark>](/cloud/compute-services/compute-engine/confidential-computing-vm/overview/limitations.md#security-boundaries-end-users-responsibility).

## Who holds the encryption keys?

<code class="expression">space.vars.ionos\_cloud</code> holds none of the following keys:

| **Key**                                                                                                                                                          | **Held by**                                                                                                                                                                                                                                                                                                                                                                                           | **Purpose**                                                                                                                                                                                   |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Memory encryption key**                                                                                                                                        | AMD Secure Processor (hardware)                                                                                                                                                                                                                                                                                                                                                                       | Encrypts VM RAM in real time. The hardware generates it per VM; it never leaves the silicon.                                                                                                  |
| [<mark style="color:blue;">**Volume Master Key (VMK)**</mark>](https://docs.ionos.com/cloud/support/general-information/glossary-of-terms#volume-master-key-vmk) | The user                                                                                                                                                                                                                                                                                                                                                                                              | Unlocks the LUKS-encrypted disk. Released into VM memory only after the VM's identity is verified.                                                                                            |
| **Attestation signing key**                                                                                                                                      | AMD ([<mark style="color:blue;">VCEK/VLEK</mark>](https://docs.ionos.com/cloud/support/general-information/glossary-of-terms#versioned-chip-endorsement-key-vcek-versioned-loaded-endorsement-key-vlek), through [<mark style="color:blue;">AMD's Key Distribution Service)</mark>](https://docs.ionos.com/cloud/support/general-information/glossary-of-terms#amd-key-distribution-service-amd-kds)) | Signs the hardware [<mark style="color:blue;">attestation report</mark>](https://docs.ionos.com/cloud/support/general-information/glossary-of-terms#attestation-report) so you can verify it. |

## What IONOS CLOUD can and cannot see

Because <code class="expression">space.vars.ionos\_cloud</code> holds no keys, it cannot produce decrypted data, not for support, not for an infrastructure incident, and not in response to a legal request.

| **IONOS CLOUD can see**                           | **IONOS CLOUD cannot see**                           |
| ------------------------------------------------- | ---------------------------------------------------- |
| That your VM exists (it is a resource in our API) | The contents of your VM's memory                     |
| Its allocated resources (cores, RAM)              | The contents of your encrypted disk                  |
| API actions (`create`, `start`, `stop`, `delete`) | Your workload (what runs and what data it processes) |

## Shared responsibility model

The boundary between <code class="expression">space.vars.ionos\_cloud</code> and the user is hardware-enforced, not policy-based.

| **Responsibility**                                                                                                                                                                                | **IONOS CLOUD** | **You (User)** |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- | -------------- |
| Physical datacenter security; host hardware and AMD SEV-SNP enablement                                                                                                                            | ✅               | —              |
| AMD SEV-SNP hardware integrity and availability                                                                                                                                                   | ✅               | —              |
| SEV-SNP enabled and enforced hypervisor                                                                                                                                                           | ✅               | —              |
| Cloud API server lifecycle management                                                                                                                                                             | ✅               | —              |
| VM memory encryption (hardware)                                                                                                                                                                   | ✅               | —              |
| [<mark style="color:blue;">OVMF</mark>](https://docs.ionos.com/cloud/support/general-information/glossary-of-terms#open-virtual-machine-firmware-ovmf) firmware build transparency and provenance | ✅               | Verify         |
| Guest OS and kernel                                                                                                                                                                               | —               | ✅              |
| Root filesystem encryption ([<mark style="color:blue;">LUKS2</mark>](https://docs.ionos.com/cloud/support/general-information/glossary-of-terms#linux-unified-key-setup-luks))                    | —               | ✅              |
| Additional block volume encryption                                                                                                                                                                | —               | ✅              |
| Attestation service for hosting and operation                                                                                                                                                     | —               | ✅              |
| Attestation service for TLS certificate management                                                                                                                                                | —               | ✅              |
| Encryption key management (VMK)                                                                                                                                                                   | —               | ✅              |
| Attestation policy definition and validation                                                                                                                                                      | —               | ✅              |
| Network traffic encryption (TLS or WireGuard)                                                                                                                                                     | —               | ✅              |
| Application security and hardening                                                                                                                                                                | —               | ✅              |
| Image preparation, artifact building, and measurement                                                                                                                                             | —               | ✅              |
| `initrd` integrity and attestation agent                                                                                                                                                          | —               | ✅              |
| Guest-side monitoring and diagnostics                                                                                                                                                             | —               | ✅              |

## Guest kernel trust boundary

Confidential VMs encrypt guest memory and prove the software stack through attestation, but trust must also extend to the devices the hypervisor presents to the guest.

A standard Linux guest kernel ships with driver support for a wide range of virtual hardware: graphical console, keyboard and mouse input, serial UART, USB controllers, host-guest socket channels (vsock), and virtual console ports. The hypervisor presents devices to the guest; the guest kernel decides whether to load a driver for each device. If a driver exists, an attack surface exists, regardless of what the hypervisor "promises."

**The principle of zero trust applies here too.** A production CVM must not trust that the hypervisor will refrain from attaching unexpected devices, reading framebuffer output, or injecting input. A stronger posture is a guest kernel that *contains no driver code for those interfaces*, ensuring that even if the hypervisor presents a virtual keyboard, no code path exists in the guest to receive keystrokes. AMD SEV-SNP attestation verifies kernel **identity**, not driver behavior directly: the measurement proves that the kernel actually running is — bit for bit — the kernel you built and supplied in the artifacts partition — not a substituted or modified one. Because you know what that specific kernel was built to do, confirming its identity confirms it carries no driver code for those interfaces, provided loadable modules are also disabled (`CONFIG_MODULES=n`) so nothing can be added to the running system outside what was measured.

**For a production CVM**, build a minimal hardened kernel that removes console, input, serial, USB, and management channel drivers at compile time. The resulting VM has a dark screen, a dead keyboard, and no serial output. These are properties of the specific kernel build whose identity the attestation measurement verifies. For more information, see [<mark style="color:blue;">How to build a hardened kernel for IONOS CLOUD CVMs</mark>](/cloud/compute-services/compute-engine/confidential-computing-vm/how-tos/hardened-cvm-kernel-howto.md).

## The user-operated security model

<code class="expression">space.vars.ionos\_cloud</code> Confidential VM is a user-operated product. The CPU enforces memory isolation in hardware; no IONOS CLOUD service, software, or personnel makes any security decisions.

{% hint style="info" %}
**Prerequisites:** This product requires Linux kernel expertise, cryptographic literacy, and the operational maturity to run a security-critical service reliably.
{% endhint %}

## What is a measurement and how is it computed?

A [<mark style="color:blue;">measurement</mark>](https://docs.ionos.com/cloud/support/general-information/glossary-of-terms#measurement) is the cryptographic identity of your Confidential VM's software stack, a `SHA-384` digest that the AMD Secure Processor computes during every VM start. It covers, in the following order:

1. OVMF firmware `firmware-code.fd`
2. Linux kernel `vmlinuz`
3. Initial ramdisk `initrd.img`
4. Kernel command-line parameters `kernel-params.txt`

The computation is deterministic, which means the same software stack always produces the same value. Any modification to any of these inputs produces a different measurement, which causes attestation to fail. The AMD Secure Processor records the measurement in a hardware-signed attestation report that your attestation service verifies at launch.

## The launch process

Every Confidential VM start is a cryptographic event. The following four steps describe how a Confidential VM reaches a running, trusted OS.

{% stepper %}
{% step %}

### Sealed startup

The VM starts with user-provided artifacts, including the kernel, `initrd`, OVMF firmware, and kernel parameters. You build these artifacts entirely yourself and embed them in the `LAUNCH_ARTIFACTS` partition. The host cannot mount the root filesystem, read it, or inject any configuration. The VM image is immutable after upload.
{% endstep %}

{% step %}

### Crypto audit

The AMD Secure Processor computes a measurement of the VM's initial software state, then generates a signed attestation report containing the launch measurement, [<mark style="color:blue;">guest policy</mark>](https://docs.ionos.com/cloud/support/general-information/glossary-of-terms#guest-policy), and hardware identity. A key derived from AMD's root of trust signs this report, meaning neither <code class="expression">space.vars.ionos\_cloud</code> nor any host-side software can forge it.
{% endstep %}

{% step %}

### `initrd` handshake *(attestation path only)*

When you use an attestation service, the `initrd` starts before the OS. Its internal attestation agent sends the hardware-signed attestation report to your attestation service over a [<mark style="color:blue;">TLS</mark>](https://docs.ionos.com/cloud/support/general-information/glossary-of-terms#transport-layer-security-tls) channel, using certificates you embedded at build time. <code class="expression">space.vars.ionos\_cloud</code> has no role in this process and cannot intercept this exchange. If you skip attestation, you still need the `initrd` to handle the disk unlock locally.

{% hint style="info" %}
**Note:** The `initrd` is the trust anchor of the entire security model. A compromised `initrd` breaks the trust chain. You build it; <code class="expression">space.vars.ionos\_cloud</code> has no access to it.
{% endhint %}
{% endstep %}

{% step %}

### Secure release *(attestation path only)*

Your attestation service verifies the report against your pre-registered policy. If all checks pass, the service releases the VMK directly into the VM's encrypted memory. The key never writes to disk and remains entirely invisible to <code class="expression">space.vars.ionos\_cloud</code>. Finally, the `initrd` decrypts the LUKS2 root filesystem, and the OS starts. For a detailed walkthrough, see [<mark style="color:blue;">Attest a Confidential VM</mark>](/cloud/compute-services/compute-engine/confidential-computing-vm/api-how-tos/attest-confidential-vm.md).

{% hint style="warning" %}
**Important:** If any check fails, the attestation service does not release the VMK, and the VM cannot start.
{% endhint %}
{% endstep %}
{% endstepper %}

## Firmware transparency

Every OVMF firmware release relies on [<mark style="color:blue;">TianoCore EDK II</mark>](https://github.com/ionos-cloud/edk2), the open-source UEFI/firmware development framework. For each release:

* A public GitHub Actions CI pipeline builds the artifact.
* GitHub's OIDC infrastructure signs the release with [<mark style="color:blue;">SLSA Level 2 provenance</mark>](https://docs.ionos.com/cloud/support/general-information/glossary-of-terms#supply-chain-levels-for-software-artifacts-slsa-provenance).
* The Sigstore Rekor public transparency log permanently records the transaction.

<code class="expression">space.vars.ionos\_cloud</code> holds no private signing keys. The Rekor log is append-only; it rejects any modification or deletion of existing entries.

For verification steps, see [<mark style="color:blue;">Verify the OVMF firmware</mark>](/cloud/compute-services/compute-engine/confidential-computing-vm/api-how-tos/prepare-confidential-vm-image.md#3-verify-the-ovmf-firmware).


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.ionos.com/cloud/compute-services/compute-engine/confidential-computing-vm/overview/security-and-trust-model.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.