accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Berman (JIRA)" <>
Subject [jira] [Created] (ACCUMULO-1749) Provide tool for assisting cert provisioning across tserver cluster
Date Fri, 04 Oct 2013 16:27:45 GMT
Michael Berman created ACCUMULO-1749:

             Summary: Provide tool for assisting cert provisioning across tserver cluster
                 Key: ACCUMULO-1749
             Project: Accumulo
          Issue Type: Sub-task
            Reporter: Michael Berman

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

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.

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.

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.

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.

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.

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.

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.

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.

This message was sent by Atlassian JIRA

View raw message