ctubbsii commented on a change in pull request #2197:
URL: https://github.com/apache/accumulo/pull/2197#discussion_r679414846
##########
File path: core/src/main/java/org/apache/accumulo/core/conf/Property.java
##########
@@ -894,6 +893,21 @@
TABLE_COMPACTION_STRATEGY_PREFIX("table.majc.compaction.strategy.opts.",
null,
PropertyType.PREFIX,
"Properties in this category are used to configure the compaction
strategy.", "1.6.0"),
+ // Crypto-related properties
+ @Experimental
+ TABLE_CRYPTO_PREFIX("table.crypto.opts.", null, PropertyType.PREFIX,
+ "Properties related to on-disk file encryption.", "2.1.0"),
+ @Experimental
+ @Sensitive
+ TABLE_CRYPTO_SENSITIVE_PREFIX("table.crypto.opts.sensitive.", null,
PropertyType.PREFIX,
+ "Sensitive properties related to on-disk file encryption.", "2.1.0"),
+ @Experimental
+ TABLE_CRYPTO_SERVICE("table.crypto.service",
+ "org.apache.accumulo.core.spi.crypto.NoCryptoService",
PropertyType.CLASSNAME,
+ "The class which executes on-disk table encryption/decryption. The
default does "
+ + "nothing. This property must be a classname with an implementation
of the "
+ + "org.apache.accumulo.core.spi.crypto.CryptoService interface.",
+ "2.1.0"),
Review comment:
I'm not a fan of the `.custom` property prefix naming convention. It
implies that we have a bag of properties segregated between "official"
properties in Accumulo property namespaces, and "unofficial" properties in a
designated namespace for user-provided plugins. But, our reference
implementations use the `.custom` property namespace in some cases but not in
others. We're not consistent. I think we should just treat it as one big bag of
well-named and well-scoped properties and relax the constraint that requires
users to use the `.custom` namespace for their properties.
So, that said, I'd be fine leaving the `table.crypto.`, rather than require
they be in `table.custom.crytpo.` or something similar. I'm not suggesting
copying the property naming convention from VolumeChooser, just the pattern of
letting the single factory instance decide whether and how to use these
properties, based on its implementation and the provided scope.
So, imagine a `MyCryptoServiceFactoryThatSupportsPerTableConfig` being set
as `instance.crypto.service.factory`. The factory has an API that is called,
something like `factory.getCryptoService(scopeConfig)`. So, depending on scope,
you'd provide different configs:
```java
var walCryptoService =
factory.getCryptoService(systemConf.getAllPropertiesWithPrefixStripped("instance.crypto.wal."));
var tableCryptoServiceForTableA =
factory.getCryptoService(tableAConf.getAllPropertiesWithPrefixStripped("table.crypto."));
```
Now, it's up to the implementation of the factory to decide what
CryptoService to return, based on the scope and scope config. (My example only
shows passing in config properties, but you could pass in the scope as a type
as well, or some other object performing a similar function of communicating
context to the factory.)
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
