About vSAN encryption

Encryption of vSAN data at rest requires a key management system (KMS). By default, key management for vSAN data encryption in Google Cloud VMware Engine uses Cloud Key Management Service for newly created private clouds, at no additional cost.

You can instead choose to deploy an external KMS for encryption of vSAN data at rest from one of the supported vendors below. This page explains vSAN encryption behavior and summarizes how to use an external KMS to encrypt virtual machine data at rest in VMware Engine.

vSAN data encryption

By default, VMware Engine enables vSAN encryption for data in the primary cluster and in clusters subsequently added to the private cloud. Encryption of vSAN data at rest uses a data encryption key (DEK) that's stored on the local physical disk of the cluster after encryption. The DEK is a FIPS 140-2 compliant AES-256 bit encryption key auto-generated by ESXi hosts. A key encryption key (KEK) supplied by the Google-managed key provider is used to encrypt the DEK.

We strongly recommend against disabling vSAN encryption of data at rest, as it can put you in violation of the service specific terms for Google Cloud VMware Engine. When you disable vSAN encryption of data at rest on a cluster, the VMware Engine monitoring logic raises an alert. To help prevent you from being in violation of service terms, this alert triggers a Cloud Customer Care-driven action to re-enable vSAN encryption on the affected cluster.

Similarly, if you configure an external KMS, we strongly recommend against deleting the key provider configuration of Cloud Key Management Service in vCenter Server.

Default key provider

VMware Engine configures vCenter Server in newly created private clouds to connect to a Google-managed key provider. VMware Engine creates one instance of the key provider per region, and the key provider uses Cloud KMS for encryption of the KEK. VMware Engine fully manages the key provider and configures it to be highly available in all regions.

The Google-managed key provider complements the native key provider in vCenter Server (in vSphere 7.0 Update 2 and later) and is the recommended approach for production environments. The native key provider runs as a process within the vCenter Server, which runs on a vSphere cluster in VMware Engine. VMware recommends against using the native key provider for encrypting the cluster that hosts vCenter Server. Instead, use the Google-managed default key provider or an external KMS.

Key rotation

When using the default key provider, you are responsible for rotation of the KEK. To rotate the KEK in vSphere, see the VMware documentation Generate New Data-At-Rest Encryption Keys.

For more ways to rotate a key in vSphere, see the following VMware resources:

Supported vendors

To switch your active KMS, you can select a third-party KMS solution that's KMIP 1.1 compliant and certified by VMware for vSAN. The following vendors have validated their KMS solution with VMware Engine and published deployment guides and support statements:

For configuration instructions, see the following documents:

Use a supported vendor

Each deployment of an external KMS requires the same basic steps:

  • Create a Google Cloud project or use an existing one.
  • Create a new Virtual Private Cloud (VPC) network or choose an existing VPC network.
  • Connect your selected VPC network to the VMware Engine service using private services access.

Then, deploy the KMS in a Compute Engine VM instance:

  1. Set up required IAM permissions to deploy Compute Engine VM instances.
  2. Deploy the KMS in Compute Engine.
  3. Establish trust between vCenter and the KMS.
  4. Enable vSAN data encryption.

The following sections briefly describe this process of using one of the supported vendors.

Set up IAM Permissions

You need sufficient permissions to deploy Compute Engine VM instances in a given Google Cloud project and VPC network, connect your VPC network to VMware Engine, and configure firewall rules for the VPC network.

Project owners and IAM principals with the Network Admin role can create allocated IP ranges and manage private connections. For more information on roles, see Compute Engine IAM roles.

Deploy key management system in Compute Engine

Some KMS solutions are available in an appliance form-factor in Google Cloud Marketplace. You can deploy such appliances by importing the OVA directly in your VPC network or Google Cloud project.

For software-based KMS, deploy a Compute Engine VM instance using the configuration (vCPU count, vMem, and disks) recommended by the KMS vendor. Install the KMS software in the guest operating system. Create the Compute Engine VM instance in a VPC network that is connected to VMware Engine using private services access.

Establish trust between vCenter and the KMS

After deploying the KMS in Compute Engine, configure your VMware Engine vCenter to retrieve encryption keys from the KMS.

First add KMS connection details to vCenter. Then, establish trust between vCenter and your KMS. To establish trust between vCenter and your KMS, do the following:

  1. Generate a certificate in vCenter.
  2. Sign it using a token or key generated by your KMS.
  3. Provide or upload that certificate to vCenter.
  4. Confirm the connectivity status by checking the KMS setting and status in the vCenter server configuration page.

Enable vSAN data encryption

In vCenter, the default CloudOwner user has sufficient privileges to enable and manage vSAN data encryption.

To switch from an external KMS back to the default Google-managed key provider, follow the steps for changing the key provider provided in the VMware documentation Configuring and Managing a Standard Key Provider.

What's next