Michael Berman created ACCUMULO-1749:
----------------------------------------
Summary: 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
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 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.1#6144)
