Integrate Nutanix AOS with CryptoHub to protect all data written to the Distributed Storage Fabric using KMIP-managed encryption keys. Configuration is performed once in Prism Element and covers every Nutanix service simultaneously. This guide covers the full workflow from deploying the CryptoHub KMIP service through enabling cluster encryption.
Nutanix AOS encrypts data at the Distributed Storage Fabric (DSF) layer using AES-256 with Intel AES-NI hardware acceleration. When configured with an external key management server, encryption keys are never stored on the cluster — every key retrieval requires a live connection to the CryptoHub. This architectural model means enabling encryption once at the cluster or container level protects all services that write to the DSF, with no per-service configuration required.
Services protected
Enabling data-at-rest encryption (DARE) at the cluster or container level covers all storage-layer traffic, regardless of which Nutanix service generated it.
| Service | How encryption applies |
|---|
| AHV VM disks | Cluster-level encryption covers all containers on AHV |
| Nutanix Volumes (iSCSI) | Data written to encrypted containers is encrypted |
| Nutanix Files (NAS) | File service VMs store data on encrypted Nutanix containers |
| Nutanix Objects (S3) | Object data on the DSF benefits from DARE |
| Self-encrypting drives (SEDs) | CryptoHub holds the authentication keys that unlock drive data bands on boot |
For dual encryption — software DARE layered over SEDs — an external KMS is required. The native Local Key Manager cannot be used for dual encryption.
Key management architecture
Nutanix uses a two-tier key hierarchy for external KMS integrations:
- Data Encryption Keys (DEKs) encrypt actual data on disk. DEKs are wrapped by Key Encryption Keys stored on the external KMS.
- Key Encryption Keys (KEKs) are AES-256 symmetric keys created and stored on the CryptoHub. Nutanix retrieves KEKs on demand via KMIP — no keys are cached on the cluster.
Because no keys are stored locally, the CryptoHub must be reachable from all Controller VMs (CVMs) during normal operations and after any cold boot or IPMI reset.
Certificate model
The mTLS connection between each CVM and the CryptoHub uses per-node X.509 certificates. Nutanix generates a unique keypair and Certificate Signing Request (CSR) for each CVM in the cluster. These CSRs are signed by the CryptoHub’s Certificate Authority. The resulting signed certificates, together with the CryptoHub CA certificate, are uploaded back to Prism Element to complete mutual TLS authentication.
This per-node certificate model means a cluster with five CVMs requires five CSRs to be signed and five certificates to be uploaded to Prism Element before encryption can be enabled.
Never host the CryptoHub on the same Nutanix cluster you intend to encrypt. If the encrypted cluster cannot reach the CryptoHub after a cold boot, all data on the cluster is inaccessible until the KMS is restored.