Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Thu, 31 Oct 2013 22:31:18 +0000 (UTC)
From: "John Vines (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12672364.1380903997474.4019.1383258678497@arcas>
In-Reply-To: <JIRA.12672364.1380903997474@arcas>
References: <JIRA.12672364.1380903997474@arcas>
Subject: [jira] [Updated] (ACCUMULO-1749) Provide tool for assisting cert
 provisioning across tserver cluster
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/ACCUMULO-1749?page=3Dcom.atlas=
sian.jira.plugin.system.issuetabpanels:all-tabpanel ]

John Vines updated ACCUMULO-1749:
---------------------------------

    Component/s: tserver
                 master
                 client

> 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
>             Fix For: 1.6.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 automat=
ed way.  Whether or not this should actually be accumulo's responsibility w=
as a contentious issue in ACCUMULO-1009.  Here are some arguments for and a=
gainst 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 ot=
her 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 envir=
onment's policies and practices. I'd prefer not trying to provide everythin=
g 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 syst=
em administrators, I think.
> {quote}
> [~mberman]
> {quote}
> Regarding provisioning scenarios, I think some people will want to use ce=
rts signed by public CAs the same way they would want to for a webserver, b=
ut I still believe this will be unwieldy for tservers. I think the much mor=
e common scenario would be for someone to generate a self-signed root on on=
e box, and then want to just cut however many more local certs on each of t=
he nodes in the cluster. As far as reducing the learning curve for system a=
dministrators, I think running bin/accumulo init-ssl on each machine, and h=
aving that generate certs in default locations and not require any addition=
al config would actually be less work than making them configure a bunch of=
 properties and figure out what relationships they want among all their cer=
ts, even if the properties point to standardish locations. Having a separat=
e 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 C=
A, 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 p=
art here>, especially when you start talking about trying to set up your ow=
n sub-root from which you can cut certificates. Requiring someone to unders=
tand 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 t=
he certificate generation and configuration for you would be my strongly pr=
eferred choice, and would make setting up secure clusters much much easier.=
 The work to set up a reasonably secure SSL deployment is boilerplate, albe=
it complex boilerplate. Unless you are extremely keen on handling this setu=
p 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 st=
uff 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 w=
hatever process they currently know or use. No re-inventing the wheel at al=
l.
> 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 any=
body go through the headache of getting every tserver cert signed by a comm=
on public root. But... it doesn't really matter whether the "real CA" is on=
e that is pre-configured in a browser (something like VeriSign's root)... s=
o long as it's easy to configure. The point is to make it easy to control w=
hich one they'll trust... which may be generated from their root, or an int=
ermediate root, or a trustStore that holds all the individual tserver publi=
c 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 inte=
rmediate cert handy. I think it would be nice for people to have an easy op=
tion 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/a=
ccumulo 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 t=
hat, or users who want security but really don't know what they're doing an=
d who just want the comfort of "security" (not a good target audience to ca=
ter to, as a rule).
> The best thing for provisioning is to simply document how one might provi=
sion certificates... perhaps as a sequence of keytool or openssl commands. =
That way, it's clear to users that Accumulo's security isn't anything speci=
al or custom or novel. It's simply leveraging the same kinds of security th=
at is available to them in other applications... the same that they may alr=
eady 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 certifi=
cate 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, certific=
ates are typically well understood and tooling exists to generate and provi=
sion. That being said, trying to shoehorn those certs into an internally-pr=
ovisioned piece is usually kludgy at best.
> I see "accumulo init" as a case where steps =E2=80=93 though complicated =
=E2=80=93 are going to be identical across users and are required to get th=
e 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 provide=
s no more security and only adds complexity. Nor will I argue that it provi=
des iron-clad security. It is a step along the path towards good security.
> It seems like from your previous comments, you think an administrator mus=
t 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 h=
ow to correctly deploy it. Deploying it properly is a mechanical issue, one=
 that can be easily automated. (By properly I am merely referring to gettin=
g actual SSL connections working, not yet to how the certificate material i=
s secured.) Once deployed, network sniffing attacks and man-in-the-middle a=
ttacks 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 tha=
n the instance secret. Every new node will require that that password be pr=
ovided, thwarting the ability to have that node deployed unattended, but ra=
tcheting up the security. One could also devise a scheme where the root cer=
tificate itself is kept offline until needed, further increasing one's abil=
ity to control access to it.
> {quote}


--
This message was sent by Atlassian JIRA
(v6.1#6144)