[KUDU-1948] Client-side configuration of cluster details

• Type: New Feature
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 1.3.0
• Component/s: client, security
• Labels: roadmap-candidate
• Target Version/s: Backlog
• Assignee: Unassigned
• Reporter: Todd Lipcon
• Created: 19/Mar/17 20:45
• Updated: 02/Jun/20 21:30

Description

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.

Issue Links

• is related to: KUDU-2255 Customized configuration on KuduClient via KuduContext
• relates to: KUDU-3143 Properties based API for client configuration