Alexey Serbin created KUDU-2265:
-----------------------------------
Summary: 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.50, 1.6.0, 1.4.0, 1.3.1, 1.3.0
Reporter: Alexey Serbin
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)
