[jira] [Commented] (KUDU-2265) A non-leader master uses self-signed server TLS cert if it hasn't ever run as a leader

["Todd Lipcon (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KUDU-2265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16331127#comment-16331127 ] 

Todd Lipcon commented on KUDU-2265:
-----------------------------------

Would be great if we could augment this message "org.apache.kudu.client.NonRecoverableException: Server requires Kerberos, but this client is not authenticated (kinit)" with something that said "Did not use available authentication token because server side does not have a trusted certificate." That would have made this easier to debug, right?

> A non-leader master uses self-signed server TLS cert if it hasn't ever run as a leader
> --------------------------------------------------------------------------------------
>
>                 Key: KUDU-2265
>                 URL: https://issues.apache.org/jira/browse/KUDU-2265
>             Project: Kudu
>          Issue Type: Improvement
>          Components: master, security
>    Affects Versions: 1.3.0, 1.3.1, 1.4.0, 1.6.0, 1.50
>            Reporter: Alexey Serbin
>            Priority: Major
>
> As it's currently implemented, master process replaces its auto-generated self-signed server TLS certificate with CA-signed one only when it becomes a leader (see {{{color:#333333}CatalogManager::InitCertAuthorityWith(){color}}} method; it's invoked only from \{{CatalogManager::InitCertAuthority()}}, that is invoked only from \{{CatalogManager::PrepareForLeadershipTask()}}).
>  
> In case of just one Raft election from the start (which is pretty common, BTW), non-leader masters run without CA-signed server certificate for a long time in case of a multi-master configuration.  That causes clients to not use their authn tokens for authentication while connecting to those non-leader masters.  In case of Spark applications where executors do not have Kerberos credentials (the common case), application logs are polluted with messages like below:
> {noformat}
> org.apache.kudu.client.NonRecoverableException: Server requires Kerberos, but this client is not authenticated (kinit)
>   at org.apache.kudu.client.Negotiator.evaluateChallenge(Negotiator.java:705)
>   at org.apache.kudu.client.Negotiator.sendSaslInitiate(Negotiator.java:581)
> ...
> Caused by: javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]
>   at com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:211){noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)