accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Slacum <wsla...@gmail.com>
Subject Re: [DISCUSS] What to do about encryption at rest?
Date Thu, 05 Nov 2015 19:11:21 GMT
Just to moonwalk back a bit, I see a few things happening concurrently now.
First is trying to get a consensus on where we want to go with the
encryption at rest story in Accumulo.

I see us having established that what we have is scoped down to working for
WALs and RFiles, and if you happen to have written it, you are satisfied.
However, as a project, we haven't pulled it into the public API and haven't
provided documentation, so if you haven't written it, the process of
finding out how to configure and use the feature is indirect.

There is some consensus about moving to using HDFS encryption to achieve
the same features, but we want to test and see if the performance is
comparable between it and Accumulo's RFile encryption capability. There may
be caveats based on how you encrypt the data. We want to explore this
space. Mike would like a Jira ticket to outline this.

For adding features to Accumulo, we could potentially add encryption at the
column level. Questions about this involve the level of effort for
supporting this because, compared to other solutions, dynamic locality
groups make this a more difficult task when compared to products with a 1:1
mapping between locality groups and column families (as well as an extra
mapping to files).

Did I miss anything?

On Thu, Nov 5, 2015 at 1:27 PM, Adam Fuchs <afuchs@apache.org> wrote:

> Camps two and three are the same camp, really. If we can identify a clear
> roadmap (eventually via the right set of tickets), then it comes down to
> whether people have energy and inclination to do the work. I don't think
> the roadmap ends here.
>
> Adam
>
> On Thu, Nov 5, 2015 at 1:18 PM, Christopher <ctubbsii@apache.org> wrote:
>
> > Perhaps. I had interpreted some of Adam's comments ("The only thing that
> > doesn't get encrypted is a temporary WAL recovery file. That is a project
> > we should take on..."), as favoring improvements to the current state of
> > things. As that has also been the focus of previous conversations about
> the
> > state of Accumulo's encryption-at-rest, I assumed that third camp also
> > existed. Perhaps I was wrong.
> >
> > On Thu, Nov 5, 2015 at 1:11 PM Mike Drob <mdrob@apache.org> wrote:
> >
> > > I think you have misidentified the two camps. There is a camp that
> > believes
> > > we should phase out the code in favour of the HDFS encryption, and a
> camp
> > > that believes the code is sufficiently mature. I don't think there is a
> > > group that is interested in improving the state of things.
> > >
> > > On Thu, Nov 5, 2015 at 12:02 PM, Christopher <ctubbsii@apache.org>
> > wrote:
> > >
> > > > JIRAs are fine, but I thought this thread was mostly addressing the
> > fact
> > > > that there doesn't seem to be a sustained interest in actually
> working
> > on
> > > > any of the JIRAs addressing that area of code. Am I wrong? Is there
> > > > willingness from anybody to expend effort on this code? Even if not,
> we
> > > can
> > > > still make JIRAs, but they'll probably just be ignored. So, the
> > question
> > > > for me is: which JIRAs should we make? Are we going to pursue phasing
> > out
> > > > the code, or pursue improving it? Those are very different JIRA text.
> > > >
> > > > On Thu, Nov 5, 2015 at 12:22 PM Mike Drob <mdrob@apache.org> wrote:
> > > >
> > > > > Can we file some JIRAs to build out a suite to test this and run
> the
> > > > > necessary tests?
> > > > >
> > > > > On Thu, Nov 5, 2015 at 11:17 AM, Christopher <ctubbsii@apache.org>
> > > > wrote:
> > > > >
> > > > > > My main concern using HDFS encryption vs. built-in Accumulo
> > > > > implementation
> > > > > > is possibly performance with respect to seeks. If we encrypt
our
> > > > indexed
> > > > > > blocks independently (as we do now), I suspect our seeks would
be
> > > more
> > > > > > performant than relying on HDFS encryption, whose encrypted
> blocks
> > > may
> > > > > not
> > > > > > fall on our index boundaries. If this is a small difference,
it
> > might
> > > > > still
> > > > > > be worth it for convenience and simpler maintenance, but I
> suspect
> > > the
> > > > > > difference will be somewhat substantial.
> > > > > >
> > > > > > On Thu, Nov 5, 2015 at 12:11 PM Josh Elser <josh.elser@gmail.com
> >
> > > > wrote:
> > > > > >
> > > > > > > +1 I think this is the right step. My hunch is that some
of the
> > > > common
> > > > > > > data access patterns that we have in Accumulo (over HBase)
is
> > that
> > > > the
> > > > > > > per-colfam encryption isn't quick as common a design pattern
as
> > it
> > > is
> > > > > > > for HBase (please tell me I'm wrong if anyone disagrees
-- this
> > is
> > > > > > > mostly a gut reaction). I think our users would likely
benefit
> > more
> > > > > from
> > > > > > > a per-namespace/table encryption control like you suggest.
> > > > > > >
> > > > > > > Implementing RFile encryption at HDFS level (e.g. tie a
> specific
> > > > > > > zone/key for a table) is probably straightforward. Changing
the
> > > > > > > TServer's WAL use would likely be trickier to get right
(a
> > tserver
> > > > > would
> > > > > > > have multiple WALs, one for each unique zone/key from Tablet
it
> > > > happens
> > > > > > > to host). Maybe worrying about that is getting ahead of
things
> --
> > > > just
> > > > > > > thought about it and figured I'd mention it :)
> > > > > > >
> > > > > > > William Slacum wrote:
> > > > > > > > Yup, #2. I also don't know if it's worth the effort
for that
> > > > specific
> > > > > > > > feature. It might be easier to add something like
> per-namespace
> > > > > and/or
> > > > > > > > per-table encryption, then define common access patterns
for
> > > > > > applications
> > > > > > > > that want to use multiple keys for encryption.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Nov 4, 2015 at 8:10 PM, Adam Fuchs<afuchs@apache.org
> >
> > > > > wrote:
> > > > > > > >
> > > > > > > >> Bill,
> > > > > > > >>
> > > > > > > >> Do you envision one of the following as the driver
behind
> > > > > > finer-grained
> > > > > > > >> encryption?:
> > > > > > > >>
> > > > > > > >> 1. We would only encrypt certain columns in order
to get
> > better
> > > > > > > >> performance;
> > > > > > > >>
> > > > > > > >> 2. We would use different keys on different columns
in order
> > to
> > > > > revoke
> > > > > > > >> access to a column via the key store;
> > > > > > > >>
> > > > > > > >> 3. We would only give a tablet server access to
a subset of
> > > > columns
> > > > > at
> > > > > > > any
> > > > > > > >> given time in order to protect something, and
figure out
> what
> > to
> > > > do
> > > > > > for
> > > > > > > >> compactions, etc.;
> > > > > > > >>
> > > > > > > >> 4. Something entirely different...
> > > > > > > >>
> > > > > > > >> Seems like thing #2 might have merit, but I'm
not sure it's
> > > worth
> > > > > the
> > > > > > > >> effort.
> > > > > > > >>
> > > > > > > >> Adam
> > > > > > > >> On Nov 4, 2015 7:38 PM, "William Slacum"<wslacum@gmail.com>
> > > > wrote:
> > > > > > > >>
> > > > > > > >>> @Adam, column family level encryption can
be useful for
> > > > > multi-tenant
> > > > > > > >>> environments, and I think it maps pretty well
to the
> document
> > > > > > > >>> partitioning/sharding/wikisearch style tables.
Things are
> > > > trickier
> > > > > in
> > > > > > > >>> Accumulo than in HBase since there isn't a
1:1 mapping
> > between
> > > > > column
> > > > > > > >>> families and files. The built in RFile encryption
scheme
> > seems
> > > > > better
> > > > > > > >>> suited to this.
> > > > > > > >>>
> > > > > > > >>> @Christopher&  Keith, it's something we
can evaluate. Is
> > there
> > > a
> > > > > good
> > > > > > > >> test
> > > > > > > >>> harness for just writing an RFile, opening
a reader to it,
> > and
> > > > just
> > > > > > > >> poking
> > > > > > > >>> around? I was looking at the constructors
and they didn't
> > seem
> > > > > > > >>> straightforward enough for me to comprehend
them within a
> few
> > > > > > seconds.
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>> On Tue, Nov 3, 2015 at 9:56 PM, Keith Turner<
> > keith@deenlo.com
> > > > > > > >>> <javascript:_e(%7B%7D,'cvml','keith@deenlo.com');>>
> wrote:
> > > > > > > >>>
> > > > > > > >>>> On Mon, Nov 2, 2015 at 1:37 PM, Keith
Turner<
> > keith@deenlo.com
> > > > > > > >>>> <javascript:_e(%7B%7D,'cvml','keith@deenlo.com');>>
> wrote:
> > > > > > > >>>>
> > > > > > > >>>>>
> > > > > > > >>>>> On Mon, Nov 2, 2015 at 12:27 PM, William
Slacum<
> > > > > wslacum@gmail.com
> > > > > > > >>>> <javascript:_e(%7B%7D,'cvml','wslacum@gmail.com');>>
> > wrote:
> > > > > > > >>>>>> Is "the code being 'at rest'"
you making a funny about
> > > active
> > > > > > > >>>> development?
> > > > > > > >>>>>> Making sure I haven't lost my
ability to get jokes :)
> > > > > > > >>>>>>
> > > > > > > >>>>>> I see two reasons why the code
would be inactive: the
> > > feature
> > > > is
> > > > > > > >> good
> > > > > > > >>>>>> enough as is or it's not interesting
enough to attract
> > > > > attention.
> > > > > > > >>>>>> Considering it's not public API,
there are no
> discussions
> > to
> > > > > bring
> > > > > > > >>> into
> > > > > > > >>>>>> the
> > > > > > > >>>>>> public API, and there's no effort
to document how to use
> > it,
> > > > my
> > > > > > > >>>> intuition
> > > > > > > >>>>>> tells me that there isn't enough
interest in it from a
> > > project
> > > > > > > >>>>>> perspective.
> > > > > > > >>>>>>
> > > > > > > >>>>>>  From a user perspective, I've
been getting asked about
> it
> > > > when
> > > > > I
> > > > > > > >> work
> > > > > > > >>>> with
> > > > > > > >>>>>> Accumulo users. My recommendation,
exclusively, is to
> use
> > > HDFS
> > > > > > > >>>> encryption
> > > > > > > >>>>>> because I can go to Hadoop's website
and find
> > documentation
> > > on
> > > > > it.
> > > > > > > >>> When
> > > > > > > >>>> I
> > > > > > > >>>>>> go to find documentation on Accumulo's
offerings, any
> > > > usability
> > > > > > > >>>>>> information
> > > > > > > >>>>>> comes from vendor SlideShares.
Most mentions of the
> > feature
> > > on
> > > > > > > >>> official
> > > > > > > >>>>>> Apache Accumulo channels echo
Christopher's sentiments
> on
> > > the
> > > > > > > >> feature
> > > > > > > >>>>>> being
> > > > > > > >>>>>> experimental and not being officially
recommended for
> use.
> > > > > > > >>>>>>
> > > > > > > >>>>>> I wouldn't want to rip out the
feature first and then
> > figure
> > > > > > things
> > > > > > > >>> out
> > > > > > > >>>>>> later. Sean already alluded to
it, but a roadmap should
> > > > contain
> > > > > > > >>>> something
> > > > > > > >>>>>> (tool or documentation) to help
users migrate if we go
> > down
> > > > that
> > > > > > > >>> route.
> > > > > > > >>>>>> What I'm trying to figure out
is, when the question of
> > "How
> > > > do I
> > > > > > do
> > > > > > > >>>>>> encryption at rest in Accumulo?"
comes up, what is our
> > > > > community's
> > > > > > > >>>> answer?
> > > > > > > >>>>>> If we went down the route of using
HDFS encryption
> zones,
> > > can
> > > > we
> > > > > > > >> offer
> > > > > > > >>>> the
> > > > > > > >>>>>> same features? At the very least,
we'd be offering the
> > same
> > > > > > > >>>> database-level
> > > > > > > >>>>> Where does the decryption happen with
DFS, is it in the
> DFS
> > > > > client?
> > > > > > > >> If
> > > > > > > >>>>> so, using HDFS level encryption seems
to offer the same
> > > > > > > >>> functionality???
> > > > > > > >>>>> Has anyone written a tool that takes
an
> > > > > > > >>>>> Accumulo-encrypted-HDFS-unencrypted-RFile
and rewrites it
> > is
> > > as
> > > > > an
> > > > > > > >>>>> Accumulo-unencrypted-HDFS-encrypted-RFile?
 Wondering if
> > > there
> > > > > are
> > > > > > > >> any
> > > > > > > >>>>> unexpected gotchas w/ this.
> > > > > > > >>>>>
> > > > > > > >>>> I was discussing my questions w/ Christopher
today and he
> > > > > mentioned
> > > > > > an
> > > > > > > >>>> experiment that I thought was interesting.
  What is the
> > > random
> > > > > seek
> > > > > > > >>>> performance of Accumulo-encrypted-HDFS-unencrypted-RFile
> vs
> > > > > > > >>>> Accumulo-unencrypted-HDFS-encrypted-RFile?
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>>>
> > > > > > > >>>>>
> > > > > > > >>>>>> encryption scheme. I don't know
the details of "more
> > > advanced
> > > > > key
> > > > > > > >>>> stores",
> > > > > > > >>>>>> but it seems like we could potentially
take any custom
> > > > > > > >> implementation
> > > > > > > >>>> and
> > > > > > > >>>>>> map it to a KeyProvider [1]. I
could also envision table
> > > level
> > > > > > > >>>> encryption
> > > > > > > >>>>>> being implementable via zones,
but probably not down to
> > the
> > > > > column
> > > > > > > >>>> family
> > > > > > > >>>>>> level.
> > > > > > > >>>>>>
> > > > > > > >>>>>> [1]
> > > > > > > >>>>>>
> > > > > > > >>>>>>
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://hadoop.apache.org/docs/r2.6.0/api/org/apache/hadoop/crypto/key/KeyProvider.html
> > > > > > > >>>>>>
> > > > > > > >>>>>> On Sun, Nov 1, 2015 at 10:19 AM,
Adam Fuchs<
> > > afuchs@apache.org
> > > > > > > >>>> <javascript:_e(%7B%7D,'cvml','afuchs@apache.org');>>
> > wrote:
> > > > > > > >>>>>>> Responses inline.
> > > > > > > >>>>>>>
> > > > > > > >>>>>>> Adam
> > > > > > > >>>>>>>
> > > > > > > >>>>>>> On Nov 1, 2015 9:58 AM, "Christopher"<
> > ctubbsii@apache.org
> > > > > > > >>>> <javascript:_e(%7B%7D,'cvml','ctubbsii@apache.org');>>
> > > wrote:
> > > > > > > >>>>>>>> 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).
> > > > > > > >>>>>>> The only thing that doesn't
get encrypted is a
> temporary
> > > WAL
> > > > > > > >>> recovery
> > > > > > > >>>>>> file.
> > > > > > > >>>>>>> That is a project we should
take on, but it does not
> > imply
> > > > that
> > > > > > > >> the
> > > > > > > >>>>>>> existing features are not
valuable. With HDFS
> encryption
> > > > > options
> > > > > > > >>> this
> > > > > > > >>>>>> would
> > > > > > > >>>>>>> now be a much easier project
to take on. Also, the
> users
> > I
> > > > know
> > > > > > > >> that
> > > > > > > >>>> use
> > > > > > > >>>>>>> encryption at rest do so with
a more secure key store
> > than
> > > > the
> > > > > > > >>>> default.
> > > > > > > >>>>>>>> 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.
> > > > > > > >>>>>>> Anybody that creates a secure
system has to analyze the
> > > > > security
> > > > > > > >> of
> > > > > > > >>>> the
> > > > > > > >>>>>>> system as a whole. Accumulo's
encryption at rest is one
> > > part
> > > > of
> > > > > > > >> the
> > > > > > > >>>>>>> solution. Taking away the
tool without providing an
> > > > alternative
> > > > > > > >> does
> > > > > > > >>>>>>> nothing to improve the security
of systems built on
> > > Accumulo.
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>> 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.
> > > > > > > >>>>>>>
> > > > > > > >>>>>>> People are using it, so we
have to consider the
> > > implications
> > > > of
> > > > > > > >>>> whatever
> > > > > > > >>>>>>> changes we make and weigh
against the benefits. I
> believe
> > > the
> > > > > > last
> > > > > > > >>> bug
> > > > > > > >>>>>> fix
> > > > > > > >>>>>>> was done this year, so I would
argue it is being
> > > maintained.
> > > > > > > >> Changes
> > > > > > > >>>> to
> > > > > > > >>>>>> our
> > > > > > > >>>>>>> encryption at rest implementation
will have
> consequences
> > > for
> > > > > > those
> > > > > > > >>>>>> users.
> > > > > > > >>>>>>> There had better be a clear
benefit if we break their
> > > > systems.
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>> 4. Has Accumulo's been
evaluated for security and
> > > > performance?
> > > > > > > >> By
> > > > > > > >>>>>> whom?
> > > > > > > >>>>>>> Is
> > > > > > > >>>>>>>> it published?
> > > > > > > >>>>>>> Yes, there have been several
talks at meetups and
> > > conferences
> > > > > > that
> > > > > > > >>>>>> discuss
> > > > > > > >>>>>>> the security and performance
of the current solution.
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>> On Sun, Nov 1, 2015, 08:55
Adam Fuchs<
> afuchs@apache.org
> > > > > > > >>>> <javascript:_e(%7B%7D,'cvml','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<javascript:_e(%7B%7D,'cvml','
> > > > 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