# Data Object - VsanHostEncryptionInfo(vim.vsan.host.EncryptionInfo)

Property of
  VsanEncryptionHealthSummary, VsanHostConfigInfoEx, VsanPrepareVsanForVcsaSpec, VsanVcPostDeployConfigSpec
Extends
  DynamicData
See also
  KmipServerSpec
Since
  vSAN API 6.6

## Data Object Description

VMware vSAN can encrypt data on the disk. Below terminologies and their acronyms are used to demonstrate how the encryption works. DEK - Data Encryption Key. Keys that are used to encryption data on each disk. Plain DEK will not be persisted by vSAN for safety. Instead, vSAN will encrypt the DEK and store the encrypted format. KEK - Key Encryption Key. A vSAN cluster will maintain a KEK that is used to encrypt the DEKs. vSAN does not persist the KEK. It only persists the Id of the KEK, and retrieve plain KEK from KMS (mentioned below) by providing the KEK's Id. KMS - Key Management Server, where KEK is generated and stored, we support KMS from several popular vendors, such as SafeNet, Thales, Vormetrics, and HyTrust. Encryption configuration for vSAN encryption service. It contains encryption enablement state, KEK Id, KMS information, client certificate, private key, and KMS certificates.

Properties

Name | Type | Description
--- | --- | ---
changing* | xsd:boolean | Whether encryption state is currently changing to have all disk groups matching the state described in enabled.
clientCert* | xsd:string | Client certificate in PEM encoding. Host will use this certificate for authentication when connecting to KMS.
clientKey* | xsd:string | Client private key. Host will use this key for authentication when connecting to KMS.
dekGenerationId* | xsd:long | Data Encryption Key (DEK) generation number.
enabled* | xsd:boolean | Encryption enablement state.
eraseDisksBeforeUse* | xsd:boolean | Whether disks should be wiped when a normal disk is converted to encrypted disk, or a disk is claimed as encrypted disk, or a disk runs deep rekey. If set true, every sector on a disk will be written with random data. Disk wipe does significantly reduce the possibility of data leak and increases the attacker's cost to reveal sensitive data. The disadvantage of disk wipe is that it takes a long time to finish, so turn it on through UI or API only when necessary. If not set, disk won't be wiped.
hostKeyId* | xsd:string | The Id of host key which is used for host core dump encryption. This should be generated by vCenter to call key management server and pass to ESXi host. ESXi host can later retrieve the key with this ID.
kekId* | xsd:string | Unique ID for the KEK in the KMS cluster. It's returned by KMS after vCenter invoking key generation operation. ESX host can retrieve the key with this ID.
kmipServers* | KmipServerSpec[] | The KMS servers where the global KEK is created and stored. Host will fetch KEK from the KMS cluster with given KEK ID.
kmsServerCerts* | xsd:string[] | Certificates of Key Management Servers in PEM encoding. Host will use these certificates to decide if a KMS should be trusted or not.
Properties inherited from DynamicData
None

*Need not be set
Show WSDL type definition
<complexType xmlns="http://www.w3.org/2001/XMLSchema" xmlns:vsan="urn:vsan" name="VsanHostEncryptionInfo"> <complexContent> <extension base="vsan:DynamicData"> <sequence> <element name="enabled" type="xsd:boolean" minOccurs="0"/> <element name="kekId" type="xsd:string" minOccurs="0"/> <element name="hostKeyId" type="xsd:string" minOccurs="0"/> <element name="kmipServers" type="vsan:KmipServerSpec" minOccurs="0" maxOccurs="unbounded"/> <element name="kmsServerCerts" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/> <element name="clientKey" type="xsd:string" minOccurs="0"/> <element name="clientCert" type="xsd:string" minOccurs="0"/> <element name="dekGenerationId" type="xsd:long" minOccurs="0"/> <element name="changing" type="xsd:boolean" minOccurs="0"/> <element name="eraseDisksBeforeUse" type="xsd:boolean" minOccurs="0"/> </sequence> </extension> </complexContent> </complexType>