ctubbsii commented on a change in pull request #2197:
URL: https://github.com/apache/accumulo/pull/2197#discussion_r681386459



##########
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:
       > So it looks like these are the only crypto properties we need to bake 
into Accumulo's Property.java:
   
   Looks mostly right to me. But, I'm not sure about the "sensitive" stuff. I 
think maybe we could just assume all crypto parameters are "sensitive". This 
really only has to do with returning the config via the public API for printing 
in the shell. We could require admin permission to retrieve/view any of those 
without creating two maps for all the opts.
   
   > instance.crypto.factory (don't think we need service in the name)
   
   Agreed on the parenthetical.
   
   > Do you think we need to keep the two we have now `instance.crypto.opts.` 
and `instance.crypto.opts.sensitive.`? The only thing I can think of is if a 
user needs generic properties for the factory itself.
   
   I'm not sure. If you use them, then the interface would probably have to 
require an `init(Map<String,String> opts, Map<String,String> sensitiveOpts)` 
method, in addition to a no-arg constructor to instantiate the class. (or just 
a single map parameter, if we drop the separate set of sensitive props).




-- 
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]


Reply via email to