> Can you explain why such restriction is necessary ? Reencryption should have a minimum impact on the cluster.
> Most likely having a currently re-encrypting node serving only demand > requests will have least preformance impact on a grid. Current design assumes that reencryption will started on all noes simultaneously. Makes sense? > 25 мая 2020 г., в 11:16, Alexei Scherbakov <alexey.scherbak...@gmail.com> > написал(а): > > I mean: serving supply requests. > > пн, 25 мая 2020 г. в 11:15, Alexei Scherbakov <alexey.scherbak...@gmail.com >> : > >> Nikolay, >> >> Can you explain why such restriction is necessary ? >> Most likely having a currently re-encrypting node serving only demand >> requests will have least preformance impact on a grid. >> >> пн, 25 мая 2020 г. в 11:08, Nikolay Izhikov <nizhi...@apache.org>: >> >>> Hello, Alexei. >>> >>> I think we want to implement this feature without nodes restart. >>> In the ideal scenario all nodes will stay alive and respond to the user >>> requests. >>> >>>> 24 мая 2020 г., в 15:24, Alexei Scherbakov < >>> alexey.scherbak...@gmail.com> написал(а): >>>> >>>> Pavel Pereslegin, >>>> >>>> I see another opportunity. >>>> We can use rebalancing to re-encrypt node data with a new key. >>>> It's a trivial procedure for me: stop a node, clear database, change a >>> key, >>>> start node and wait for rebalancing to complete. >>>> Data will be re-encrypted during rebalancing. >>>> >>>> Did I miss something ? >>>> >>>> пт, 22 мая 2020 г. в 16:14, Ivan Rakov <ivan.glu...@gmail.com>: >>>> >>>>> Folks, >>>>> >>>>> Just keeping you informed: I and my colleagues are highly interested >>> in TDE >>>>> in general and keys rotations specifically, but we don't have enough >>> time >>>>> so far. >>>>> We'll dive into this feature and participate in reviews next month. >>>>> >>>>> -- >>>>> Best Regards, >>>>> Ivan Rakov >>>>> >>>>> On Sun, May 17, 2020 at 10:51 PM Pavel Pereslegin <xxt...@gmail.com> >>>>> wrote: >>>>> >>>>>> Hello, Alexey. >>>>>> >>>>>>> is the encryption key for the data the same on all nodes in the >>>>> cluster? >>>>>> Yes, each encrypted cache group has its own encryption key, the key is >>>>>> the same on all nodes. >>>>>> >>>>>>> Clearly, during the re-encryption there will exist pages >>>>>>> encrypted with both new and old keys at the same time. >>>>>> Yes, there will be pages encrypted with different keys at the same >>> time. >>>>>> Currently, we only store one key for one cache group. To rotate a key, >>>>>> at a certain point in time it is necessary to support several keys (at >>>>>> least for reading the WAL). >>>>>> For the "in place" strategy, we'll store the encryption key identifier >>>>>> on each encrypted page (we currently have some unused space on >>>>>> encrypted page, so I don't expect any memory overhead here). Thus, we >>>>>> will have several keys for reading and one key for writing. I assume >>>>>> that the old key will be automatically deleted when a specific WAL >>>>>> segment is deleted (and re-encryption is finished). >>>>>> >>>>>>> Will a node continue to re-encrypt the data after it restarts? >>>>>> Yes. >>>>>> >>>>>>> If a node goes down during the re-encryption, but the rest of the >>>>>>> cluster finishes re-encryption, will we consider the procedure >>>>> complete? >>>>>> I'm not sure, but it looks like the key rotation is complete when we >>>>>> set the new key on all nodes so that the updates will be encrypted >>>>>> with the new key (as required by PCI DSS). >>>>>> Status of re-encryption can be obtained separately (locally or cluster >>>>>> wide). >>>>>> >>>>>> I forgot to mention that with “in place” re-encryption it will be >>>>>> impossible to quickly cancel re-encryption, because by canceling we >>>>>> mean re-encryption with the old key. >>>>>> >>>>>>> How do you see the whole key rotation procedure will work? >>>>>> Initial design for re-encryption with "partition copying" is described >>>>>> here [1]. I'll prepare detailed design for "in place" re-encryption if >>>>>> we'll go this way. In short, send the new encryption key cluster-wide, >>>>>> each node adds a new key and starts background re-encryption. >>>>>> >>>>>> [1] >>>>>> >>>>> >>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652384#TDE.Phase-3.Cachekeyrotation.-Copywithre-encryptiondesign >>>>>> . >>>>>> >>>>>> вс, 17 мая 2020 г. в 18:35, Alexey Goncharuk < >>> alexey.goncha...@gmail.com >>>>>> : >>>>>>> >>>>>>> Pavel, Anton, >>>>>>> >>>>>>> How do you see the whole key rotation procedure will work? Clearly, >>>>>> during >>>>>>> the re-encryption there will exist pages encrypted with both new and >>>>> old >>>>>>> keys at the same time. Will a node continue to re-encrypt the data >>>>> after >>>>>> it >>>>>>> restarts? If a node goes down during the re-encryption, but the rest >>> of >>>>>> the >>>>>>> cluster finishes re-encryption, will we consider the procedure >>>>> complete? >>>>>> By >>>>>>> the way, is the encryption key for the data the same on all nodes in >>>>> the >>>>>>> cluster? >>>>>>> >>>>>>> чт, 14 мая 2020 г. в 11:30, Anton Vinogradov <a...@apache.org>: >>>>>>> >>>>>>>> +1 to "In place re-encryption". >>>>>>>> >>>>>>>> - It has a simple design. >>>>>>>> - Clusters under load may require just load to re-encrypt the data. >>>>>>>> (Friendly to load). >>>>>>>> - Easy to throttle. >>>>>>>> - Easy to continue. >>>>>>>> - Design compatible with the multi-key architecture. >>>>>>>> - It can be optimized to use own WAL buffer and to re-encrypt pages >>>>>> without >>>>>>>> restoring them to on-heap. >>>>>>>> >>>>>>>> On Thu, May 14, 2020 at 1:54 AM Pavel Pereslegin <xxt...@gmail.com> >>>>>> wrote: >>>>>>>> >>>>>>>>> Hello Igniters. >>>>>>>>> >>>>>>>>> Recently, master key rotation for Apache Ignite Transparent Data >>>>>>>>> Encryption was implemented [1], but some security standards (PCI >>>>> DSS >>>>>>>>> at least) require rotation of all encryption keys [2]. Currently, >>>>>>>>> encryption occurs when reading/writing pages to disk, cache >>>>>> encryption >>>>>>>>> keys are stored in metastore. >>>>>>>>> >>>>>>>>> I'm going to contribute cache encryption key rotation and want to >>>>>>>>> consult what is the best way to re-encrypting existing data, I see >>>>>> two >>>>>>>>> different strategies. >>>>>>>>> >>>>>>>>> 1. In place re-encryption: >>>>>>>>> Using the old key, sequentially read all the pages from the >>>>>> datastore, >>>>>>>>> mark as dirty and log them into the WAL. After checkpoint pages >>>>> will >>>>>>>>> be stored to disk encrypted with the new key (as usual, along with >>>>>>>>> updates). This strategy requires store the identifier (number) of >>>>> the >>>>>>>>> encryption key into the encrypted page. >>>>>>>>> pros: >>>>>>>>> - can work in the background with minimal performance impact >>>>> (this >>>>>>>>> impact can be managed). >>>>>>>>> cons: >>>>>>>>> - page duplication in the WAL may affect performance and >>>>> historical >>>>>>>>> rebalance. >>>>>>>>> >>>>>>>>> 2. Copy partition with re-encryption. >>>>>>>>> This strategy is similar to partition snapshotting [3] - create >>>>>>>>> partition copy encrypted with the new key and then replace the >>>>>>>>> original partition file with the new one (see details [4]). >>>>>>>>> pros: >>>>>>>>> - should work faster than "in place" re-encryption. >>>>>>>>> cons: >>>>>>>>> - re-encryption in active cluster (and on unstable topology) can >>>>> be >>>>>>>>> difficult to implement. >>>>>>>>> >>>>>>>>> (See more detailed comparison [5]) >>>>>>>>> >>>>>>>>> Re-encryption of existing data is a long and rare procedure (It is >>>>>>>>> recommended to change the key every 6 months, but at least once >>>>> every >>>>>>>>> 2 years). Thus, re-encryption can be implemented for maintenance >>>>> mode >>>>>>>>> (for example, on a stable topology in a read-only cluster) and in >>>>>> such >>>>>>>>> case the approach with partition copying seems simpler and faster. >>>>>>>>> >>>>>>>>> So, what do you think - do we need "online" re-encryption and which >>>>>> of >>>>>>>>> the proposed options is best suited for this? >>>>>>>>> >>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-12186 >>>>>>>>> [2] >>>>>> https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf >>>>>>>>> [3] >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-43%3A+Cluster+snapshots#IEP-43:Clustersnapshots-Partitionscopystrategy >>>>>>>>> [4] >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652384#TDE.Phase-3.Cachekeyrotation.-Copywithre-encryptiondesign >>>>>>>>> . >>>>>>>>> [5] >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652384#TDE.Phase-3.Cachekeyrotation.-Comparison >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> Best regards, >>>> Alexei Scherbakov >>> >>> >> >> -- >> >> Best regards, >> Alexei Scherbakov >> > > > -- > > Best regards, > Alexei Scherbakov
