accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [DISCUSS] What to do about encryption at rest?
Date Sun, 01 Nov 2015 14:58:22 GMT
1. I'm not sure I'd call an incomplete solution 'great'. What it does is
provide partial encryption-at-rest protection (unless you're running
without walogs, and have good integration with some external secure key
management faculty, and then it's probably fine).

2. I'm concerned that anybody using Accumulo's E-A-R don't necessarily
realize its current shortcomings, or its lack of upstream maintenance
support (which it has not been receiving). It may be the case that these
users have support from an intermediary, and do understand the
shortcomings... I don't know, but it's a concern.

3. Correction: it has been an explicitly experimental feature and an
incomplete one, which hasn't really been touched in two years, and has been
explicitly excluded by the community for being public API because of its
incompleteness. Age doesn't determine public API status. The community does.

4. Has Accumulo's been evaluated for security and performance? By whom? Is
it published?

On Sun, Nov 1, 2015, 08:55 Adam Fuchs <afuchs@apache.org> wrote:

> There's another way to look at the state of Accumulo's encryption at rest:
> 1. Encryption at rest works great for what it does, and the code being "at
> rest" isn't necessarily a problem
> 2. Several organizations are using Accumulo's encryption at rest
> effectively in operations
> 3. Encryption at rest has been a supported configuration option for over
> two years with established plugin interfaces, and therefore it should be
> considered part of the public API
> 4. Upstream alternatives (to my knowledge) have not been analyzed for
> performance or security
>
> The given option #2 would at least require an analysis of alternatives, and
> we would have to decide what to do about backwards compatibility for users
> using custom key stores and encryption strategies that may or may not be
> supported by upstream alternatives.
>
> As far as option #1 goes, I can get behind encouraging people to take up
> projects to improve Accumulo's encryption. I think we're already going down
> this path, but without having identified resources to do the improvements.
> Any volunteers?
>
> Adam
>
>
> On Fri, Oct 30, 2015 at 4:22 PM, William Slacum <wslacum@gmail.com> 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
> >
> > Any input is welcomed & appreciated!
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message