dsmiley commented on code in PR #121: URL: https://github.com/apache/solr-sandbox/pull/121#discussion_r2251912841
########## ENCRYPTION.md: ########## @@ -10,20 +10,26 @@ obviously the key secret is never stored). It is possible to define a different provides an EncryptionRequestHandler so that a client can trigger the (re)encryption of a Solr Core index. The (re)encryption is done concurrently while the Solr Core can continue to serve update and query requests. +A custom key "cookie" can be stored in the commit metadata if it is required to get the key secret. For example, it can +be the key secret in a wrapped (encrypted) form that only a Key Management System can decrypt. + In addition, the Solr update logs are also encrypted when the Solr Core index is encrypted. When the active encryption key changes for the Solr Core, the re-encryption of the update logs is done synchronously when an old log file is opened for addition. This re-encryption is nearly as fast as a file copy. +This module also ensures that replication and backup can copy and restore the index files in their encrypted form. + Comparing with an OS-level encryption: - OS-level encryption [1][2] is more performant and more adapted to let Lucene leverage the OS memory cache. It can manage encryption at block or filesystem level in the OS. This makes it possible to encrypt with different keys -per-directory, making multi-tenant use-cases possible. If you can use OS-level encryption, prefer it and skip this -Java-level encryption. +per-directory, making multi-tenant use-cases possible. If you control and can use an OS-level encryption, prefer it +compared to this Java-level encryption. - Java-level encryption can be used when the OS-level encryption management is not possible (e.g. host machine managed by a cloud provider), or when even admin rights should not allow to get clear access to the index files. It has an -impact on performance: expect -20% on most queries, -60% on multi-term queries. +impact on performance: expect -20% on most queries, -60% on multi-term queries. Although, the impact could be less Review Comment: nit: it's easier to maintain/diff a sentence per line. Okay to not do. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
