Master key rotation required in case of it compromising or at the end of crypto period (key validity period).
Design assumes that administrator will provide ability to get new master key by EncryptionSPI
from underlying storage.
New master key should be available to EncryptionSPI
for each server node. The cluster should be active.
Users can control the master key rotation process key via some kind of user interface(CLI, JMX, Java API).
ignite.encryption().changeMasterKey(String masterKeyName)
- starts master key rotation process.String ignite.encryption().getMasterKeyName()
- gets current master key name.changeMasterKey(String masterKeyName)
- starts master key rotation process.String getMasterKeyName()
- gets current master key name.control.sh --encryption change_master_key newMasterKeyName
control.sh --encryption get_master_key_name
Master key change process consist of two phases:
Each phase is a distributed process.
The goal is to verify that all server nodes have the same master key. A server node starts prepare phase with the MasterKeyChangeRequest
that contains:
Each server node executes following actions:
It obtains a digest of a new master key. If the digest is unavailable then the process completes with the error.
The coordinator starts the perform phase when the prepare phase completed without errors.
The coordinator node starts prepare phase with the MasterKeyChangeRequest
that contains:
Each server node executes following actions:
ChangeMasterKeyRecord
) that consist of:MetaStore
.Distributed process is a cluster-wide process that accumulates single nodes results to finish itself.
The process consists of the following phases:
InitMessage
sent via discovery.SingleNodeMessage
sent via communication.FullMessage
sent via discovery.Several processes of one type can be started at the same time.
The process completes when the perform phase completed (all nodes was re-encrypts their keys).
If some node was unavailable during master key rotation process it will unable to join to the cluster because it has old master key.
To update this node user should run ignite with system property (IGNITE_MASTER_KEY_NAME_TO_CHANGE_BEFORE_STARTUP=newMasterKeyName
)
The node will re-encrypt cache keys with new MK and try to join to cluster.
A node should not try to join to the cluster before the process of ChangeMasterKeyRecord
. Regardless of whether the key rotation was finished successfully or not, the recovery will be from the record.
ChangeMasterKeyRecord
it passed to EncryptionManager
.EncryptionManager
writes new cache group keys to it.Reject node join. It may lead to inconsistent master keys in cluster.
Cache keys must not be created during the master key rotation process. So, a node will throw an exception if a user will start cache during the key rotation process. Moreover, if group keys were generated before the master key change the cache start will be rejected (case of client node starts the cache).
The node will process the critical error failure. Failure handler must stop the node to prevent inconsistent keys in the cluster.
The concept of the masterKeyId will be added to the cache keys encryption process in EncryptionSpi
:
New methods will be introduced:
setMasterKeyName(String masterKeyName)
// Sets "current" master key nameString getMasterKeyName()
// Gets "current" master key nameFollow methods will work with master key that setted by previous method:
byte[] masterKeyDigest()
byte[] encryptKey(Serializable key)
Serializable decryptKey(byte[] key)
This is necessary so that ignite can decrypt cache keys with the old master key and encrypt with the new one.
Meta storage will store master key name. Key name from meta storage has a higher priority to key name from EncryptionSpi
.
Currently joining node send hash MK for validation in attributes. Attributes can't be modified at runtime. So joining node will send hash MK in JoiningNodeDiscoveryData
.