Cloudera Navigator HSM KMS Overview
In addition to existing Navigator Key Trustee KMS (KT KMS) solutions (see Configuring the Key Management Server (KMS)), Cloudera offers the Navigator Hardware Security Module Key Management Server (HSM KMS) solution, which provides an additional encryption model (other encryption models include the Java Keystore KMS and KT KMS) to ensure the greatest level of encryption security for an enterprise’s HDFS data.
- Encryption zone keys (EZ keys) originate on and never leave the HSM. This is a significant reason to select an HSM KMS over the existing KMS implementations, as it provides the highest level of EZ key security.
- The HSM KMS root of trust model differs from the model found in the existing KT KMS. KT KMS employs a client-based trust model, where there is an exchange of GPG
keys that enable the client and server to identify and communicate with each other privately. For some, this client-based trust level of GPG key exchange can be a bit of a challenge to manage and
administer. So, the HSM KMS model can be easier to manage in terms of the exchange of root of trust because the HSM is the root of trust and always secures the EZ key(s)
For details on the client prerequisites and installation instructions for the available HSM KMS solutions, see:
For details about resource planning for HSM KMS, see Navigator HSM KMS HA Planning.
Data Privacy with HSM KMS: Encryption Zone Key Creation and Management
As mentioned previously, in the Navigator HSM KMS architecture the EZ key originates in and never leaves the HSM.
With the HSM KMS, EZ key generation occurs in the HSM device, meaning that the actual key being used to encrypt data encryption keys for HDFS encryption is created within the HSM, and never leaves the HSM. All EDEK encryption and decryption operations happen within the HSM, providing the greatest level of encryption zone key protection.
For additional details about encryption keys and zones, see Managing Encryption Keys and Zones.
HSM KMS High Availability (HA) Support
The HSM KMS supports HA using a two-node, leaderless HA model. Both nodes in the HSM KMS configuration are active, and both nodes are first-class providers of the KMS proxy service, meaning one node can be down while the other node continues to operate as normal.
The HSM KMS HA model also provides a durability guarantee for the two-node topology. When an EZ key is created or rolled, the information is written to at least two nodes before returning to the client. In this way, if there is a failure of one node, you can rest assured that there is always at least one copy of the EZ key on the other node that was created. So, when there are two nodes, data is written to both nodes before returning to the client.
Essentially, the HA model dictates writes to the number of nodes required by the durability guarantee, and then the remainder of synchronization operations occur in the background.
For details about how to enable HSM KMS HA, refer to Enabling Navigator HSM KMS High Availability.