[
https://issues.apache.org/jira/browse/ACCUMULO-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated ACCUMULO-1749:
---------------------------------
Fix Version/s: (was: 1.7.0)
1.8.0
> Provide tool for assisting cert provisioning across tserver cluster
> -------------------------------------------------------------------
>
> Key: ACCUMULO-1749
> URL: https://issues.apache.org/jira/browse/ACCUMULO-1749
> 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 context.
> [~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
(v6.3.4#6332)
