At the risk of sounding snarky (not trying to) I really don't understand our current security model when Kerberos is turned off. Validating authentication and authorization rules when user identity is easily spoofable is annoying and also not secure (because, well, security is turned off). Case in point, as alluded to by Todd, is having to type "sudo -u kudu kudu cluster ksck" to run ksck as of Kudu 1.4. It's silly.
AFAICT, authentication enforcement when Kerberos is disabled serves no useful purpose. In non-secure mode Kudu should simply skip all kinds of authn and authz. For people who need the current rules (I can't see why they would) we could add a flag to enable it (maybe called --believe-remote-clients-without-auth). My 2c, Mike On Wed, Jun 21, 2017 at 1:28 PM, Alexey Serbin <[email protected]> wrote: > I also think it's better to not introduce environment-controlled behavior > into the Kudu C++ client library itself. I'm in favor of Dan's proposal. > > If I remember correctly, there was an idea to implement some sort of > configuration for the client library via config file. That's a separate > theme on its own, but if it's going to be implemented, keeping off the > environment-controlled behavior from the client library makes more sense in > that context as well. It also makes more sense to avoid introducing > environment-controlled behavior if we want to keep the C++ and the Java > client parity to some extent. > > Having the explicit run-time flag for the CLI tool might be even a better > option. And it would be nice if that worked for the Kerberized setup as > well (maybe, in the future). > > > Best regards, > > Alexey > > > > On 6/21/17 11:06 AM, Dan Burkert wrote: > >> I'm in favor of providing an easy to use workaround for this case, but I'd >> like to see it implemented a bit differently. I think the user name >> should >> be an option in the Kudu client builder (alongside e.g. >> import_authentication_credentials >> <https://github.com/cloudera/kudu/blob/master/src/kudu/clien >> t/client.h#L240>), >> and the application (in this case the kudu tool) would be responsible for >> reading an environment variable and setting it appropriately (or perhaps >> via a gflag). Same effect in the end, but I don't think pure libraries >> should be reading things from the environment. >> >> All that being said, I'd also be in favor of KUDU_USER over the longer >> variants, since changing the username is not inherently insecure; the >> 'source' of the insecurity is the cluster's configuration, not the client >> configuration. >> >> - Dan >> >> On Wed, Jun 21, 2017 at 10:52 AM, Todd Lipcon <[email protected]> wrote: >> >> Hey folks, >>> >>> I had the occasion yesterday of trying to run an admin tool from my >>> laptop >>> (as user 'todd') against an insecure cluster (running as user 'kudu'). >>> The >>> cluster was rejecting me because I wasn't in the admin/service ACLs, >>> which >>> was somewhat annoying. >>> >>> I worked around the problem by locally hacking my copy of user.cc to >>> ignore >>> my actual username and just return "kudu" :) >>> >>> I think it's good that we have authorization enabled even in insecure >>> clusters, since it reduces test variables and prevents "accidental" usage >>> of higher privileges. So, I don't think we should disable the above >>> behavior. >>> >>> That said, it's inconvenient to have to recompile Kudu to spoof a user >>> against an insecure cluster. Given that it's already easy to spoof for a >>> malicious user, does anyone have an objection to making it easier for >>> non-malicious users to spoof by respecting some environment variable like >>> KUDU_USER or KUDU_INSECURE_USER or KUDU_SPOOF_USER or somesuch? >>> >>> -Todd >>> -- >>> Todd Lipcon >>> Software Engineer, Cloudera >>> >>> >
