And definitely this approach is much simplier to implement because all corner cases are handled by rebalancing code.
пн, 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 > -- Best regards, Alexei Scherbakov
