You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kudu.apache.org by "Todd Lipcon (JIRA)" <ji...@apache.org> on 2017/03/19 20:46:41 UTC

[jira] [Created] (KUDU-1948) Client-side configuration of cluster details

Todd Lipcon created KUDU-1948:
---------------------------------

             Summary: Client-side configuration of cluster details
                 Key: KUDU-1948
                 URL: https://issues.apache.org/jira/browse/KUDU-1948
             Project: Kudu
          Issue Type: New Feature
          Components: client, security
    Affects Versions: 1.3.0
            Reporter: Todd Lipcon


In the beginning, Kudu clients were configured with only the address of the single Kudu master. This was nice and simple, and there was no need for a client "configuration file".

Then, we added multi-masters, and the client API had to take a list of master addresses. This wasn't awful, but started to be a bit aggravating when trying to use tools on a multi-master cluster (who wants to type out three long hostnames in a 'ksck' command line every time?).

Now with security, we have a couple more bits of configuration for the client. Namely:
- "require SSL" and "require authentication" booleans -- necessary to prevent MITM downgrade attacks
- custom Kerberos principal -- if the server wants to use a principal other than 'kudu/<HOST>@REALM' then the client needs to know to expect it and fetch the appropriate service ticket. (Note this isn't yet supported but would like to be!)

In the future, there are other items that might be best specified as part of a client configuration as well (e.g. CA cert for BYO PKI, wire compression options, etc).

For the above use cases it would be nicer to allow the various options to be specified in a configuration file rather than adding specific APIs for all options.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)