THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Key rotation required in case of it compromising or at the end of crypto period(key validity period).
Goal:
To implement ability to rotate cache encryption key.
New processes:
Cache key rotation.
Removal of cache key.
New administrator commands:
Current state of cache key rotation: node -> group name -> status -> encryption key hash.
Cache group keys rotation:
Process start:
Administrator initiates process via some kind of user interface(CLI, Visor, WebConsole, JMX, etc).
Process description:
New key generated using configured EncryptionSPI.
Message with new key(encrypted with master key) is sent by discovery.
On message receive following actions are executed:
Process state: IN PROGRESS.
New key saved in metastore(WAL record about this event is written to the disk).
Further WAL records are encrypted with the new key.
Further page are encrypted with the new key.
Pages reencryption process is initiated.
Pages reencryption process description:
Process uses it's own Thread pool.
Thread pool configured in IgniteConfiguration.
For each partition file.
File readed page by page.
For each page(following steps executed by many thread using producer-consumer pattern):
Page is blocked from write operation into regular Ignite Durable Memory.
Page is readed(from file) into memory. Note, this process doesn“t use regular Offheap Ignite pages.
Page decrypted with previous key.
Page encrypted with new key.
Page is written into file.
Page id is added to reencrypted pages set(Bloom filter as it has constant size).
Page is unblocked.
Progress of reencryption is saved to WAL for failover after each X pages processed. X is configured in IgniteConfiguration.
End of each partition process is saved to WAL.
Process state: FINISHED.
Motivation:
Memory footprint [Thread count]*[page size]
Minor affect on regular data operations.
Doesn“t displace hot pages from RAM during file scan process.
Page decryption during reencryption process:
During reencryption process page may be encrypted with previous key OR with new key.
To decrypt page we have to do the following steps:
Block page from reencryption.
Check in reencrypted pages set is this page processed(see «Pages reencryption process description» #3.6)
If page not reencrypted yet we use old key for decryption.
If page reported as reencrypted(Bloom filter may be false positive) we:
Try to decrypt page with new key.
If fail we should try to use old key.
Unblock page from reencryption.
Process failover:
If node fails in the middle of reencryption process we should resume reencryption process on node start.
We should do following steps for started but not finished partition file:
Find last progress record in WAL.
Scan partition from the beginning to last progress record point and just add eache page to reencrypted pages set.
After it we have X pages that MAY BE reencrypted(and may be not). We should find fir not reencrypted page:
Trying to decrypt page with new key.
If fails then page is found.
We should continue reencryption process starting from it.
Process completion:
Administrator initiates process completion via interface by using “cache key removal” command.
Design assume, administrator will check that all nodes successfully change cache key and reencrypt all pages and all required nodes are alive.
Cache group keys removal:
Process start:
Administrator initiates process via some kind of user interface(CLI, Visor, WebConsole, JMX, etc).
Process description:
Message is sent by discovery.
Message should contain:
new cache key hash.
When server node processed message following actions are executed:
Received cache key hash compared with known cache key hash.
Previous cache key removed from MetaStore.
Monitoring command:
Reencryption process state.
- Input: cache id.
- Output:
- List of Tuples6
- Node ID
- Reencryption process state.
- Count of partition to process.
- Current partition index.
- Current partition id.
- Count of processed page in current partition.
- List of Tuples6
Overview
Content Tools
Apps
