This page describes the management of a Key Management System (KMS) within the WEKA system.
When creating an encrypted filesystem, a KMS must be used to secure the encryption keys properly.
The WEKA system uses the KMS to encrypt filesystem keys. When the WEKA system comes up, it uses the KMS to decrypt the filesystem keys and its in-memory capabilities for data encrypting/decrypting operations.
When a snapshot is taken using the Snap-To-Object feature, the encrypted filesystem key is saved along with the encrypted data. When rehydrating this snapshot to a different filesystem (or when recovering from a disaster to the same filesystem in the WEKA cluster), the KMS decrypts the filesystem key. Consequently, the same KMS data must be present when performing such operations.
For increased security, the WEKA system does not save any information that can reconstruct the KMS encryption keys, performed by the KMS configuration alone. Therefore, the following should be considered:
- 1.If the KMS configuration is lost, the encrypted data may also be lost. Therefore, a proper DR strategy should be set when deploying the KMS in a production environment.
- 2.The KMS must be available when the WEKA system comes up when a new filesystem is created and from time to time when key rotations must be performed. Therefore, it is recommended that the KMS be highly available.
The WEKA system supports the following KMS types:
The KMS is the only source holding the key to decrypt WEKA system filesystem keys. For non-disruptive operations, it is highly recommended to follow these guidelines:
- Set up DR for the KMS (backup/replication) to avoid data loss.
- Ensure that the KMS is highly available. A single URL in the WEKA system represents the KMS.
- Provide access to the KMS from the WEKA backend servers.
Taking a Snap-To-Object ensures that the (encrypted) filesystems keys are backed up to the object store. This is essential if a total corruption of the WEKA system configuration occurs.