accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: Config in ZooKeeperInstance
Date Tue, 23 Jul 2013 21:02:22 GMT
It should really be a conscious decision whether to create a client
that expects SSL enabled or not. It shouldn't just happen

For comparison, imagine if HTTP/SSL worked this way... when I type
https://.... I expect it to be serving over SSL... not just
auto-negotiate to secure or non-secure mode. If it's not in secure
mode when I navigate to https://... , I simply don't want to go there.
Now, browsers do auto-negotiate in the other direction, to secure mode
(via HTTP redirects to HTTPS addresses), but that only works because
your browser has a set of built-in certificate authorities that it
trusts. If it doesn't, your browser gives you an error (if it's a good
browser) or a warning (if it's a weak one). So, even auto-negotiating
to secure mode is problematic if you can't control from the client,
which certificates the client is willing to trust in that secure
communication. We have no sensible way to distribute certificates that
clients should trust. Sysadmins should generate their own certificates
and configure clients appropriately.

So, I don't see a way around it, you're going to have to make the
client code aware that SSL is the desired mode of communication...
either through a constructor parameter to ZooKeeperInstance, or
through another Instance sub-class... perhaps one that reads a
configuration file from the user's home directory with standard JSSE
properties (
You should not just automatically retrieve this from the server's
configuration in ZooKeeper, because that assumes you already trust the
server, and that undermines the whole point of the authentication
component of SSL.

There's also the question of enabling SSL on ZK itself. I think you'd
probably want to do that, too. You're still going to need to seed the
SSL attributes in the client configuration, though, before you talk to
any other server. I suppose you could trust ZK, and manage keys there
(still seeding the client, but only with the certs / ssl mode needed
to talk directly to ZK)... but I think that might be overkill for a
first pass (especially since you can probably re-use the same server
cert for ZK as you can for the other servers... since they are
operating as a system). I think a simpler and more reliable solution
is to enable the easy configuration of standard JSSE properties in
both the client and the server.

Now, what we could do is leave the configuration getter/setter on the
instance, and require setting JSSE options for SSL in that, via
setConfiguration(), though I'm personally a fan of getting them
automatically from a properties file instead (like the
$HOME/.accumulorc or $HOME/.accumulo/config suggestion made on
ACCUMULO-1045, or maybe even /etc/accumulo/clients.conf or similar).

Christopher L Tubbs II

On Tue, Jul 23, 2013 at 1:38 PM, Michael Berman <> wrote:
> The reason I'm interested in the config from a ZooKeeperInstance is because
> a ZKInstance needs to know whether or not to use SSL to try to connect to a
> given cluster.  I think it would be annoying to require a ZKInstance client
> to explicitly specify "useSsl" any time they want to connect to an SSL
> tserver (although I do see value in having a "requireSsl" optional flag).
>  If configuration isn't the right way to communicate this, do people have
> other suggestions?  I suppose I could just throw an ssl:// on the front of
> the connection string or something, but it seems kludgy to do that any time
> there's a configuration option that we want clients to know about.
> As far as removing Instance.getConfiguration() entirely, there are about 30
> references throughout the codebase to getConfiguration() on a bare
> Instance.  Finding some other way to plumb whatever options those consumers
> care about through the stack sounds like a substantial project.
> In my use case, I am only interested in the configuration that's stored in
> ZK, and I already have enough information to connect to ZK, so it doesn't
> seem difficult technically, just a question of desired behavior.
> On Tue, Jul 23, 2013 at 1:11 PM, Eric Newton <> wrote:
>> +1 for removing it from Instance
>> On Tue, Jul 23, 2013 at 12:14 PM, Christopher <> wrote:
>> > It only returns the default config if you don't call
>> > setConfiguration(), which appears to be almost always (except
>> > TestIngest).
>> >
>> > I don't know that this API is clearly spelled out, as to its intended
>> > purpose. Which configuration is it supposed to be getting, and how
>> > does that relate to the ZooKeeperInstance? The only configuration a
>> > ZooKeeperInstance has is the minimum needed to connect to other
>> > servers. It still has to authenticate to read any other server
>> > configuration.
>> >
>> > Personally, I'd be in favor of removing it from Instance interface,
>> > unless we actually document what it is supposed to be for to justify
>> > its utility in, and relationship to, the Instance interface.
>> >
>> > --
>> > Christopher L Tubbs II
>> >
>> >
>> >
>> > On Tue, Jul 23, 2013 at 10:44 AM, Michael Berman <>
>> > wrote:
>> > > I was surprised to find that ZooKeeperInstance.getConfiguration() seems
>> > to
>> > > return only the default configuration rather than the configuration
>> > stored
>> > > in ZK.  Is this the expected behavior?  I came across this in a
>> MacTest,
>> > so
>> > > if other people are also surprised, it may be a MAC or MacTest-specific
>> > > issue, in which case I'm happy to track it down.
>> > >
>> > > If this is currently the expected behavior, how would people feel about
>> > > changing it?  It seems like it would be useful to have a config channel
>> > to
>> > > ZooKeeperInstance clients (in my case, what I'm specifically interested
>> > in
>> > > is whether or not SSL is enabled).  There may be a potential for
>> > privileged
>> > > information to escape...table settings, for example, may be
>> sensitive...
>> > > But all the really secret stuff should be in the site.xml which
>> wouldn't
>> > > get exposed.
>> > >
>> > > For reference, ZooKeeperInstance's getConfiguration() is implemented
>> as:
>> > > AccumuloConfiguration.getDefaultConfiguration()
>> > >
>> > > whereas HdfsZooInstance's getConfiguration() is:
>> > > ZooConfiguration.getInstance(this, getSiteConfiguration())
>> > >
>> > > My proposal would be to change ZooKeeperInstance's to something like:
>> > > ZooConfiguration.getInstance(this,
>> > > AccumuloConfiguration.getDefaultConfiguration())
>> > >
>> > > Michael
>> >

View raw message