Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
2.3.0
-
None
-
None
Description
Following authentication code in kafka still puzzles me (Lines 67-74: https://github.com/apache/kafka/blob/3cdc78e6bb1f83973a14ce1550fe3874f7348b05/clients/src/main/java/org/apache/kafka/common/security/authenticator/SaslServerCallbackHandler.java).
private void handleAuthorizeCallback(AuthorizeCallback ac) {
String authenticationID = ac.getAuthenticationID();
String authorizationID = ac.getAuthorizationID();
LOG.info("Successfully authenticated client: authenticationID={}; authorizationID={}.",
{{ authenticationID, authorizationID);}}
ac.setAuthorized(true);
ac.setAuthorizedID(authenticationID);
}
In a kafka cluster secured with Kerberos, using a kafka keytab with principal like `sys_read/reader.myorg.corp@MYORG.CORP` results in:
authenticationID = sys_read@MYORG.CORP;
authorizationID = sys_read/reader.myorg.corp@MYORG.CORP
Last line of above method sets the authorizedID to authenticationID not authorizationID. From my understanding of java security, the principal will become what's set in AuthorizedID.
This means the ACL definitions can't use the full principal string as the principal as authorizer will never see it. This leads to a confusing bug in spark structured streaming where the ACL has to be added without the host part of the principal.