Details
Minor Description
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.
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.