Some colleagues have expressed interest in examining the current state of our rfile encryption with the expectation to suggest improvements or contributions to close the gap. I don't know a timeline for any of that, if that interest even bears out in terms of concrete action, so I don't know how much that should count right now. However, I wouldn't wrote off our encryption at rest just yet.
That said, I agree it's currently in a dead state, and if it continues that way, without progress to close the gaps in its implementation, it might be best to scrap it for now until such time as we can refactor the RFile API to ease improvements in that area of the code all around. As is, its API is way more complex than it needs to be, and I'd bet it's scaring of potential contributions. On Fri, Oct 30, 2015, 16:37 Josh Elser <[email protected]> wrote: > > > William Slacum wrote: > > So I've been looking into options for providing encryption at rest, and > it > > seems like what Accumulo has is abandonware from a project perspective. > > There is no official documentation on how to perform encryption at rest, > > and the best information from its status comes from year (or greater) old > > ticket comments about how the feature is still experimental. Recently > there > > was a talk that described using HDFS encryption zones as an alternative. > > > > From my perspective, this is what I see as the current situation: > > > > 1- Encryption at rest in Accumulo isn't actively being worked on > > 2- Encryption at rest in Accumulo isn't part of the public API or > marketed > > capabilities > > 3- Documentation for what does exist is scattered throughout Jira > comments > > or presentations > > 4- A viable alternative exists that appears to have feature parity in > HDFS > > encryption > > 5- HBase has finer grained encryption capabilities that extend beyond > what > > HDFS provides > > > > Moving forward, what's the consensus for supporting this feature? > > Personally, I see two options: > > > > 1- Start going down a path to bring the feature into the forefront and > > start providing feature parity with HBase > > > > or > > > > 2- Remove the feature and place emphasis on upstream encryption offerings > > +1 > > I'm only smart enough to know that I'm not smart enough to build a > distributed database *and* encrypt it securely. I'd much prefer to defer > to the people up the stack. > > The one thing we'd miss out on is things like column-family-level > encryption control (which I think HBase has), but I'd much rather have a > complete encryption story before worrying about the fine-grained support. > > > Any input is welcomed& appreciated! > > >
