PircDef commented on pull request #1968:
URL: https://github.com/apache/accumulo/pull/1968#issuecomment-806080969
> With both of these, the main point is that there is only ever a single
crypto service for the system. However, the functionality of that service is
capable of providing crypto services for multiple tables and/or the WAL. Your
change just relocates the implementation into inner classes, but they are still
effectively separate classes that are configured separately, meaning separate
authorities for managing the file-based crypto.
One of the goals for the crypto service in 2.0 was to make it more modular.
Admins should be able to replace crypto services as necessary. Any new service
needs to be capable of decrypting existing data. This means it needs to be able
to decrypt any data encrypted by all prior services. As it stands now, all
decrypters from all prior services would need to be part of the current crypto
service. These changes remedy that by allowing prior crypto services to
continue to provide their own decrypters.
There is a case to be made for table specific crypto services. Allowing for
table-level configuration enables data owners to control the crypto for their
data in their table. Consider a case where someone wants to bulk import
existing RFiles into a new table in another Accumulo instance. Lets assume they
use a custom crypto service. With table-level crypto services, they would need
to provide their RFiles and crypto service in order to read the data without
requiring any changes to existing crypto services.
I think it is a good idea to explicitly specify the default crypto service
used by Accumulo if a table is not specifically configured. This could allow
for a single authority when appropriate. Would another option such as:
instance.allow.table.crypto=false
be a reasonable compromise? This would allow admins to explicitly enable or
disable table-level crypto services.
--
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.
For queries about this service, please contact Infrastructure at:
[email protected]
