Azure confidential virtual machines FAQ

Confidential VMs are an IaaS solution for tenants with high security and confidentiality requirements. Confidential VMs offer:

• Encryption for "data in use”, including the processor state and the virtual machine’s memory. The keys are generated by the processor and never leave it.
• Host attestation helps you verify the full health and compliance of the server before data processing begins.
• Hardware Security Module (HSM) can be attached to guard the keys of confidential VM disks, which the tenant exclusively owns.
• New UEFI boot architecture supporting the guest OS for enhanced security settings and capabilities.
• A dedicated virtual Trusted Platform Module (TPM) certifies the health of the VM, provides hardened key management, and supports use cases such as BitLocker.

Confidential VMs address customer concerns about moving sensitive workloads off-premise into the cloud. Confidential VMs provide elevated protections for customer data from the underlying infrastructure and cloud operators. Unlike other approaches and solutions, you don't have to adapt your existing workloads to fit the platform's technical needs.

SEV-SNP stands for Secure Encrypted Virtualization-Secure Nested Paging. It's a Trusted Execution Environment (TEE) technology provided by AMD and offers multiple protections: For example, memory encryption, unique CPU keys, encryption for the processor register state, integrity protection, firmware rollback prevention, side channel hardening, and restrictions on interrupt and exceptions behavior. Collectively, AMD SEV technologies harden guest protections to deny hypervisor and other host management code access to VM memory and state. Confidential VMs leverages AMD SEV-SNP with Azure technologies such as full-disk encryption and Azure Key Vault Managed HSM. You can encrypt data in use, in transit, and at rest with keys that you control. With built-in Azure Attestation capabilities, you can independently establish trust in the security, health, and underlying infrastructure of your confidential VMs.

Intel TDX stands for Intel Trust Domain Extensions (Intel TDX) It a Trusted Execution Environment (TEE) technology provided by Intel and offers multiple protections: Intel TDX uses hardware extensions for managing and encrypting memory and protects both the confidentiality and integrity of the CPU state. Additionally, Intel TDX helps to harden the virtualized environment by denying the hypervisor, other host management code, and administrators access to the VM memory and state. Confidential VMs combine Intel TDX with Azure technologies such as full-disk encryption and Azure Key Vault Managed HSM. You can encrypt data in use, in transit, and at rest with keys that you control.

Azure VMs already offer industry leading security and protection against other tenants and malicious intruders. Azure confidential VMs augment these protections by using hardware-based TEEs such as AMD SEV-SNP and Intel TDX to cryptographically isolate and protect your data confidentiality and integrity. No host admins, or host services (including the Azure hypervisor) can directly view or modify the memory or CPU state of your confidential VM. Moreover, with full attestation capability, full OS disk encryption, and hardware-protected virtual Trusted Platform Modules, the persistent state is protected such that your private keys, and the contents of your memory are not exposed to the hosting environment unencrypted.

Currently OS disks for confidential VMs can be encrypted and secured. For extra security, you can enable guest level encryption (such as BitLocker or dm-crypt) for all data drives.

Yes, but only if the pagefile.sys is located on the encrypted OS disk. On confidential VMs with a temp disk, the pagefile.sys file can be moved to the encrypted OS Tips for moving pagefile.sys to the c:\ drive.

No, this capability doesn't exist for confidential VMs.

Here are some ways you can deploy a confidential VM:

• Deploy from the Azure portal
• Deploy from the Azure Command-Line Interface (Azure CLI)
• Deploy using an ARM Template
• Deploy using VMSS and Confidential Disk Encryption

Azure confidential VMs on AMD SEV-SNP undergo attestation as part of their boot phase. This process is opaque to the user and takes place in the cloud operating system with the Microsoft Azure Attestation and Azure Key Vault services. Confidential VMs also allow users to perform independent attestation for their confidential VMs. This attestation happens using new tooling called Azure confidential VM Guest Attestation. Guest attestation allows customers to attest that their confidential VMs are running on AMD processors with SEV-SNP enabled.

Azure confidential VMs using Intel TDX can be attested transparently as part of the boot flow to ensure the platform is compliant and up-to-date. The process is opaque to the user and takes place using Microsoft Azure Attestation and Azure Key Vault. If you would like to go further to perform checks post-boot, in-guest platform attestation is available. This allows you to verify that your VM is running on genuine Intel TDX. To access the feature, visit our preview branch. Additionally, we support Intel® Trust Authority for enterprises seeking operator independent attestation. Support for full in-guest attestation, similar to AMD SEV-SNP is coming soon. This allows organizations to go deeper, and validate further aspects, even down to the guest application layer.

To run on a confidential VM, OS images must meet certain security and compatibility requirements. This allows confidential VMs to be securely mounted, attested to, and isolated from the underlying cloud infrastructure. In the future, we plan to provide guidance on how to take a custom Linux build and apply a set of open-source patches to qualify it as a confidential VM image.

Yes. You can use Azure Compute Gallery to modify a confidential VM image, such as by installing applications. Then, you can deploy confidential VMs based on your modified image.

The optional full-disk encryption scheme is Azure's most secure and meets the Confidential Computing principles. However, you can also use other disk encryption schemes along with or instead of full-disk encryption. If you use multiple disk encryption schemes, double encryption might negatively affect performance.

Each Azure confidential VM has its own virtual TPM, where customers can seal their secrets/keys. It's recommended for customers to verify vTPM status (via TPM.msc for Windows VMs). If status isn't ready for use, we recommend that you reboot your VMs before sealing secrets/keys to vTPM.

No. After you've created a confidential VM, you can't deactivate or reactivate full-disk encryption. Create a new confidential VM instead.

Developers seeking further "separation of duties" for TCB services from the cloud service provider should use security type "NonPersistedTPM".

• This experience is only available as part of the Intel TDX public preview. Organizations that use it, or provide services with it are in control of the TCB and the responsibilities that come along with it.
• This experience bypasses the native Azure services, allowing you to bring your own disk encryption, key management, and attestation solution.
• Each VM still has a vTPM, which should be used to retrieve hardware evidence, however the vTPM state isn't persisted through reboots, meaning this solution is excellent for ephemeral workloads and organizations wanting decoupling from the cloud service provider.

No. For security reasons, you must create a confidential VM as such from the start.

Yes, converting from one confidential VM to another confidential VM is allowed on both DCasv5/ECasv5 and DCesv5/ECesv5 in the regions that they share. If you're using a Windows image, make sure you have all the most recent updates. If you're using an Ubuntu Linux image, make sure you're using the Ubuntu 22.04 LTS confidential image with the minimum kernel version 6.2.0-1011-azure.

Make sure you've selected an available region for confidential VMs. Also make sure to select clear all filters in the size selector.

No. Confidential VMs don't support Accelerated Networking. You can't enable Accelerated Networking for any confidential VM deployment, or any Azure Kubernetes Service cluster deployment that runs on Confidential Computing.

You might receive the error Operation could not be completed as it results in exceeding approved standard DCasv5/ECasv5 Family Cores Quota. This Azure Resource Manager template (ARM template) error means the deployment failed because of a lack of Azure compute cores. Azure free trial subscriptions don't have a large enough core quota for confidential VMs. Create a support request to increase your quota.

ECasv5-series and ECesv5-series are memory-optimized VM sizes, which offer a higher memory-to-CPU ratio. These sizes are especially well-suited for relational database servers, medium to large caches, and in-memory analytics.

No. At this time, these VMs are only available in select regions. For a current list of available regions, see VM products by region.

Azure doesn't have operating procedures for granting confidential VM access to its employees, even if a customer authorizes the access. As a result, various recovery and support scenarios aren't available for confidential VMs.

No, confidential VMs don't currently support nested virtualization, such as the ability to run a hypervisor inside a VM.

Billing for confidential VMs depends on your usage and storage, and the size and region of the VM. Confidential VMs use a small encrypted virtual machine guest state (VMGS) disk of several megabytes. VMGS encapsulates the VM security state of components such the vTPM and UEFI bootloader. This disk might result in a monthly storage fee. Also, if you choose to enable the optional full-disk encryption, encrypted OS disks incur higher costs. For more information on storage fees, see the pricing guide for managed disks. Lastly, for some high security and privacy settings, you might choose to create linked resources, such as a Managed HSM Pool. Azure bills such resources separately from the confidential VM costs.

Rarely some DCesv5/ECesv5-series VMs may experience a small time difference from UTC. A long term fix is available for this soon. In the meantime here are the workarounds for Windows and Ubuntu Linux VMs:

sc config vmictimesync start=disabled
sc stop vmictimesync

For Ubuntu Linux images, run the following script:

#!/bin/bash

# Backup the original chrony.conf file
cp /etc/chrony/chrony.conf /etc/chrony/chrony.conf.bak

# check chronyd.service status
status=$(systemctl is-active chronyd.service)

# check chronyd.service status is "active" or not
if [ "$status" == "active" ]; then
  echo "chronyd.service is active."
else
  echo "chronyd.service is not active. Exiting script."
  exit 1
fi

# Comment out the line with 'refclock PHC /dev/ptp_hyperv'
sed -i '/refclock PHC \/dev\/ptp_hyperv/ s/^/#/' /etc/chrony/chrony.conf

# Uncomment the lines with 'pool ntp.ubuntu.com' and other pool entries
sed -i '/#pool ntp.ubuntu.com/ s/^#//' /etc/chrony/chrony.conf
sed -i '/#pool 0.ubuntu.pool.ntp.org/ s/^#//' /etc/chrony/chrony.conf
sed -i '/#pool 1.ubuntu.pool.ntp.org/ s/^#//' /etc/chrony/chrony.conf
sed -i '/#pool 2.ubuntu.pool.ntp.org/ s/^#//' /etc/chrony/chrony.conf

echo "Changes applied to /etc/chrony/chrony.conf. Backup created at /etc/chrony/chrony.conf.bak."

echo "Restart chronyd service"
systemctl restart chronyd.service


echo "Check chronyd status"
systemctl status chronyd.service