9.4 Workload & Infrastructure Encryption

Choose the Encryption Layer

Objective 2.2 includes securing workloads and infrastructure with encryption. VM encryption, vSAN data-at-rest encryption, vSAN data-in-transit encryption and encrypted vMotion protect different paths. Selecting one does not automatically establish the others. Start with the asset and threat: stolen storage media, exposure during migration, transport between storage hosts, or access to VM files outside their authorized context.

VM encryption protects supported VM files and disks through the vSphere encryption framework and an encryption policy. vSAN data-at-rest encryption operates at the storage layer and protects the datastore's media. It does not make the guest's network sessions encrypted. An HTTPS certificate protects a management endpoint; it is not the key that unlocks every encrypted virtual disk.

Key Providers and Recovery

A key provider supplies the key material needed by supported encryption features. A standard external provider uses a supported Key Management Interoperability Protocol (KMIP) service and configured trust. Native Key Provider (NKP) is managed through vCenter and distributes the material needed by participating hosts. These models have different dependencies; neither removes the need to protect key backups and test recovery.

Create the provider through the supported vCenter workflow, validate trust and connectivity, and complete the required NKP backup before use. Protect the export and its password separately from the encrypted workloads. A backup of encrypted VM data is not sufficient if the required key material cannot be recovered. Account for a full-site outage, a new host and a restored vCenter, rather than testing only a VM reboot while the existing hosts retain keys.

A Data Encryption Key (DEK) protects data; a Key Encryption Key (KEK) protects the DEK in applicable storage encryption designs. Rekeying can involve changing a wrapping key or rewriting data with new encryption material. Follow the feature-specific shallow/deep rekey process and assess capacity, performance and recovery effects. Do not treat all rekey actions as a harmless certificate renewal.

Apply and Verify a VM Policy

First confirm the supported host, VM compatibility, datastore and guest/device prerequisites. Verify that a functioning key provider is selected and that the operator has the required cryptographic privileges. Create or choose an encryption-capable VM storage policy, then apply it to the supported VM home and disk objects under the documented power-state conditions. Some transitions require the VM to be powered off; do not promise that every encryption operation is online.

After the operation, inspect the encryption and policy state of the intended objects. Test a controlled power operation and a supported migration, then validate the backup product's encryption support. If an operation fails, determine whether the missing dependency is keys, privileges, unsupported device configuration, policy compatibility or storage capacity. Giving every operator full cryptographic access is not an appropriate substitute for identifying the failed requirement.

A virtual Trusted Platform Module (vTPM) introduces another protection and recovery consideration. Verify its encryption/key requirements and guest recovery procedures before cloning, restoring or moving a VM. Retain application or operating-system recovery material such as the approved disk-encryption recovery key. Removing a vTPM to make a migration succeed can break the guest's security/recovery expectations.

Encryption and Storage Efficiency

Data encrypted before reaching storage has less repeated/compressible content. VM encryption and storage-layer encryption therefore affect storage efficiency differently. Do not assume double encryption always improves the design. Broadcom's vSAN encryption FAQ distinguishes VM encryption from vSAN encryption and identifies restrictions for global deduplication in the documented 9.x configuration. Check the exact release and entitlement before combining features.

Worked Failure Scenario

A team restores encrypted VM disks onto replacement hosts but cannot power on the VM. The restored files demonstrate data preservation; they do not establish key availability. Check the provider registration, recovered key backup, host access and cryptographic privileges. Compare the error with a storage-policy incompatibility before changing the VM. Deleting encryption settings or resetting certificates blindly can make recovery harder.

For a complete lab exercise, record the chosen protection layer, provider, policy and recovery dependencies; deploy a disposable encrypted VM; verify its supported migration and backup; and test recovery using the documented key procedure. Store the result with the recovery runbook. Success means the authorized workload can be restored while its protected data remains inaccessible without the required keys.

Review Takeaways

• VM, vSAN-media, vSAN-transport and vMotion encryption protect different layers.
• Create and back up Native Key Provider before using its protected workloads.
• Encrypted data backups also need a recoverable key-provider design.
• Encryption transitions and rekey operations have feature-specific power-state and recovery requirements.