accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <>
Subject [jira] [Updated] (ACCUMULO-1749) Provide tool for assisting cert provisioning across tserver cluster
Date Sun, 05 Apr 2015 05:53:34 GMT


Josh Elser updated ACCUMULO-1749:
    Fix Version/s:     (was: 1.7.0)

> Provide tool for assisting cert provisioning across tserver cluster
> -------------------------------------------------------------------
>                 Key: ACCUMULO-1749
>                 URL:
>             Project: Accumulo
>          Issue Type: Sub-task
>          Components: client, master, tserver
>            Reporter: Michael Berman
>            Priority: Minor
>             Fix For: 1.8.0
> Provisioning certs off a private root for each tserver is an annoying and repetitive
task.  It would be nice for some of it to be done in an automated way.  Whether or not this
should actually be accumulo's responsibility was a contentious issue in ACCUMULO-1009.  Here
are some arguments for and against the feature; see the thread on the original issue for more
> [~ctubbsii]:
> {quote}
> Automatic cert provisioning within Accumulo itself seems out of scope to me (if it were
me, I'd rather use the system's certs in /etc/pki/tls/certs/, which is the default location
for the Apache web server and a bunch of other apps, and uniquely identify the server cryptographically).
> As long as we make sure Accumulo can be configured easily, we'll set the groundwork for
any provisioning utility or practice that users are already familiar with for their other
secure applications, according to their environment's policies and practices. I'd prefer not
trying to provide everything when those functions already exist in Linux environments in standard
ways. Instead, we should leverage those standard practices, and document how to interact with
them. This significantly reduces the learning curve for system administrators, I think.
> {quote}
> [~mberman]
> {quote}
> Regarding provisioning scenarios, I think some people will want to use certs signed by
public CAs the same way they would want to for a webserver, but I still believe this will
be unwieldy for tservers. I think the much more common scenario would be for someone to generate
a self-signed root on one box, and then want to just cut however many more local certs on
each of the nodes in the cluster. As far as reducing the learning curve for system administrators,
I think running bin/accumulo init-ssl on each machine, and having that generate certs in default
locations and not require any additional config would actually be less work than making them
configure a bunch of properties and figure out what relationships they want among all their
certs, even if the properties point to standardish locations. Having a separate root and trust
tree for accumulo also provides some additional protection. I may not want to trust any accumulo
that has a cert signed by a public CA, since anyone could have a cert signed by a public CA.
If my cluster has its own root, I can be confident that any cert signed by that root is part
of my cluster.
> {quote}
> [~mallen]:
> {quote}
> Getting "real" certificates is a pain in the <insert your favorite body part here>,
especially when you start talking about trying to set up your own sub-root from which you
can cut certificates. Requiring someone to understand how to do all that and then set up a
bunch of configuration properties on top of it puts up a big barrier to entry.
> Having something like Michael's suggested bin/accumulo init-ssl call do the certificate
generation and configuration for you would be my strongly preferred choice, and would make
setting up secure clusters much much easier. The work to set up a reasonably secure SSL deployment
is boilerplate, albeit complex boilerplate. Unless you are extremely keen on handling this
setup yourself, or your company has stringent requirements in this area, having a very easy
to set up SSL configuration is a big boon.
> I also agree that being able to quickly test an SSL-enabled mini-cluster is another huge
win for making this code easily testable and maintainable.
> {quote}
> [~ctubbsii]:
> {quote}
> It's not always about reducing the work... sometimes, it's about doing stuff in the way
they already know how to do (or have already done). I'd much rather not re-invent the wheel
for provisioning certs. If we just make it simple to configure certs, system administrators
can just provision using whatever process they currently know or use. No re-inventing the
wheel at all.
> As for "real CA" signing... I expect a common use case would be to use an intermediate
CA that is signed by a "real CA". I'm not suggesting that anybody go through the headache
of getting every tserver cert signed by a common public root. But... it doesn't really matter
whether the "real CA" is one that is pre-configured in a browser (something like VeriSign's
root)... so long as it's easy to configure. The point is to make it easy to control which
one they'll trust... which may be generated from their root, or an intermediate root, or a
trustStore that holds all the individual tserver public certs. The point is to not make decisions
for users regarding certificate provisioning, and to just make it easy for them to use what
they want.
> {quote}
> [~mberman]:
> {quote}
> There's absolutely nothing preventing you from provisioning certs the way you know how,
assuming you already know how and you happen to have an intermediate cert handy. I think it
would be nice for people to have an easy option as well if they're not already so equipped.
And as Michael Allen says above, there are definitely security and operational reasons for
wanting a separate trust tree for your accumulo deployment.
> {quote}
> [~ctubbsii]:
> {quote}
> By providing a "security on" button, you're encouraging users to not even think about
security by creating an easy button (like your proposed "bin/accumulo init-ssl") that presumably
implements some sort of security without thinking about what kind of security, what protections
it offers, and what risks it mitigates. This is a bad precedent, and it feels like your coding
to developers (like us, for ease in testing) rather than users... either that, or users who
want security but really don't know what they're doing and who just want the comfort of "security"
(not a good target audience to cater to, as a rule).
> The best thing for provisioning is to simply document how one might provision certificates...
perhaps as a sequence of keytool or openssl commands. That way, it's clear to users that Accumulo's
security isn't anything special or custom or novel. It's simply leveraging the same kinds
of security that is available to them in other applications... the same that they may already
understand, or that is well documented, or that they can get help with on StackOverflow or
the countless message boards.
> {quote}
> [~_alexm]:
> {quote}
> I'll throw in my $0.02; in short, resist the temptation to handle certificate provisioning.
> If provisioning is included, it becomes a type of one-off product that:
> - does its own thing
> - has to be maintained
> - security/admin folks have to address separately as a one-off
> When key/truststores can be reused between services, it makes life of the admin a lot
easier. For users that require encryption in transit, certificates are typically well understood
and tooling exists to generate and provision. That being said, trying to shoehorn those certs
into an internally-provisioned piece is usually kludgy at best.
> I see "accumulo init" as a case where steps – though complicated – are going to be
identical across users and are required to get the thing up and running, whereas the generation
of certificates is going to vary a bit and is still optional.
> {quote}
> [~mallen]:
> {quote}
> I disagree that providing an easy and automated way to set up SSL provides no more security
and only adds complexity. Nor will I argue that it provides iron-clad security. It is a step
along the path towards good security.
> It seems like from your previous comments, you think an administrator must make the leap
from no security to all security in one bound. I think this is a mistake. Database administrators
are not all familiar with SSL, and how to correctly deploy it. Deploying it properly is a
mechanical issue, one that can be easily automated. (By properly I am merely referring to
getting actual SSL connections working, not yet to how the certificate material is secured.)
Once deployed, network sniffing attacks and man-in-the-middle attacks are thwarted, even if
all Accumulo tserver nodes in the system have access to the issuing CA.
> Securing the issuing CA can just be a matter of having the administrator use a password
for the root certificate's private key that is different than the instance secret. Every new
node will require that that password be provided, thwarting the ability to have that node
deployed unattended, but ratcheting up the security. One could also devise a scheme where
the root certificate itself is kept offline until needed, further increasing one's ability
to control access to it.
> {quote}

This message was sent by Atlassian JIRA

View raw message