[
https://issues.apache.org/jira/browse/KUDU-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Serbin reopened KUDU-1927:
---------------------------------
While working on AuthTokenIssuingTest.ChannelConfidentiality test, I noticed
that implementation of MasterServiceImpl::ConnectToMaster() allowed for getting
a success response without proper authn/security information in case if the
master hasn't been established as a leader yet. By examining the code further
I found that could happen not only at the very first startup of a master, but
also during master re-elections in case of multi-master setup.
If a legit client connects to master but it does not get CA cert and authn
token, it might be a situation when it works flawlessly with masters and tablet
servers using its Kerberos credentials, but the exported authentication
credentials contain neither CA cert nor authn token. The latter is very
surprising in cases when the credentials are later imported by other Kudu
client applications that do not have Kerberos credentials in their environment.
If so, the client is not able to connect to a secured Kudu cluster at all.
This seems to be in contradiction with POLA, so I think it's worth fixing this.
> Potential race handling ConnectToMaster RPCs during leader transition
> ---------------------------------------------------------------------
>
> Key: KUDU-1927
> URL: https://issues.apache.org/jira/browse/KUDU-1927
> Project: Kudu
> Issue Type: Bug
> Components: master, security
> Affects Versions: 1.3.0
> Reporter: Todd Lipcon
> Assignee: Alexey Serbin
> Priority: Major
> Fix For: 1.4.0
>
>
> MasterServiceImpl::ConnectToMaster currently has a TODO that there might be a
> case where a client issues the RPC exactly as a leader is becoming active.
> The worry is that it may return a response indicating LEADER status, but
> without the ability to issue a key.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
