ctubbsii commented on pull request #1968:
URL: https://github.com/apache/accumulo/pull/1968#issuecomment-808476222
I'm thinking something like:
```java
public interface CryptoService {
enum Scope {WAL, RFILE}
FileEncrypter getEncrypter(Context); // where Context contains information
like {Scope=RFILE, Config=tableConfig(t1)}
FileDecrypter getDecrypter(Context);
}
```
> Lets assume that an Accumulo instance is running with the default crypto
service (AESCryptoService) enabled. User A wants to import their table, and
they have a custom encrypter/decrypter.
I would argue for them using a CryptoService that supports their custom
encrypter/decrypter features, as well as any others that the rest of the system
supports. The config to indicate to the service which encrypter/decrypter
features/algorithms/etc. to use can still be per-table config... but the crypto
service responsible for interpreting those config options is inside the
centrally configured CryptoService implementation, and not living inside
Accumulo core code.
Right now, it seems that this is the workflow:
* Accumulo determines the context and gathers context information (table
config, WAL config, etc.)
* Accumulo retrieves a user-configured crypto service from the context
* The crypto service provides the encrypter/decrypter for that context
My argument is for a workflow that looks like:
* Accumulo determines the context and gathers context information (table
config, WAL config, etc.)
* Accumulo passes the context to the singleton crypto service
* The crypto service provides an encrypter/decrypter appropriate for the
given context
This moves the decision making about which encrypter/decrypter to use into
the singleton CryptoService, and removes Accumulo's responsibility to
manage/instantiate multiple crypto services for different contexts, and removes
the user's responsibility to configure multiple crypto services, rather than
simply different crypto algorithms/options for a singleton crypto service.
--
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]