Kafka auf Cloudera - test = TOPIC_AUTHORIZATION_FAILED

Question

Wir haben gerade ein Upgrade von CDH 5.3.6 auf 5.10.0 durchgeführt und Fehler beim Schreiben von Kafka-Themen bekommen. Wir haben die Standardeinstellungen für alles, keine SSL- oder Kerberos-Authentifizierung aktiviert. Wenn ich den Konsolenproduzenten verwende, um in eines meiner Themen zu schreiben, erhalte ich folgende Fehlermeldung:

/usr/bin/kafka-konsolenerzeuger --broker-list = myhost1.dev.com: 9092, myhost2.dev. com: 9092 --topic Test

17/03/06 21:00:57 INFO utils.AppInfoParser: Kafka version : 0.10.0-kafka-2.1.0 
17/03/06 21:00:57 INFO utils.AppInfoParser: Kafka commitId : unknown 
x 
17/03/06 21:00:59 WARN clients.NetworkClient: Error while fetching metadata with correlation id 0 : {test=TOPIC_AUTHORIZATION_FAILED} 

Mit Blick auf/var/log/kafka/sehe ich ein Bündel von diesen Ausnahmen:

2017-03-06 21:00:26,964 WARN org.apache.sentry.provider.common.HadoopGroupMappingService: Unable to obtain groups for ANONYMOUS 
java.io.IOException: No groups found for user ANONYMOUS 
    at org.apache.hadoop.security.Groups.noGroupsForUser(Groups.java:190) 
    at org.apache.hadoop.security.Groups.getGroups(Groups.java:210) 
    at org.apache.sentry.provider.common.HadoopGroupMappingService.getGroups(HadoopGroupMappingService.java:60) 
    at org.apache.sentry.provider.common.ResourceAuthorizationProvider.getGroups(ResourceAuthorizationProvider.java:167) 
    at org.apache.sentry.provider.common.ResourceAuthorizationProvider.doHasAccess(ResourceAuthorizationProvider.java:97) 
    at org.apache.sentry.provider.common.ResourceAuthorizationProvider.hasAccess(ResourceAuthorizationProvider.java:91) 
    at org.apache.sentry.kafka.binding.KafkaAuthBinding.authorize(KafkaAuthBinding.java:212) 
    at org.apache.sentry.kafka.authorizer.SentryKafkaAuthorizer.authorize(SentryKafkaAuthorizer.java:63) 
    at kafka.server.KafkaApis$$anonfun$kafka$server$KafkaApis$$authorize$2.apply(KafkaApis.scala:321) 
    at kafka.server.KafkaApis$$anonfun$kafka$server$KafkaApis$$authorize$2.apply(KafkaApis.scala:321) 
    at scala.Option.map(Option.scala:146) 
    at kafka.server.KafkaApis.kafka$server$KafkaApis$$authorize(KafkaApis.scala:321) 
    at kafka.server.KafkaApis$$anonfun$30.apply(KafkaApis.scala:702) 
    at kafka.server.KafkaApis$$anonfun$30.apply(KafkaApis.scala:702) 
    at scala.collection.TraversableLike$$anonfun$partition$1.apply(TraversableLike.scala:314) 
    at scala.collection.TraversableLike$$anonfun$partition$1.apply(TraversableLike.scala:314) 
    at scala.collection.immutable.Set$Set1.foreach(Set.scala:94) 
    at scala.collection.TraversableLike$class.partition(TraversableLike.scala:314) 
    at scala.collection.AbstractTraversable.partition(Traversable.scala:104) 
    at kafka.server.KafkaApis.handleTopicMetadataRequest(KafkaApis.scala:702) 
    at kafka.server.KafkaApis.handle(KafkaApis.scala:79) 
    at kafka.server.KafkaRequestHandler.run(KafkaRequestHandler.scala:60) 
    at java.lang.Thread.run(Thread.java:745) 

ich für eine Lösung dieses Problems gesucht haben, aber sind bis jetzt leer ausgegangen. Muss ich den ANONYMOUS Benutzer irgendwo einigen Gruppen zuweisen? Ich konnte Nachrichten zu meinen Themen in CDH 5.3.6 schreiben, aber es scheint, dass beim Upgrade etwas schief gelaufen ist.

Nur versuchen, das helloWorld/Quickstart-Beispiel nach dem Upgrade auf CDH 5.10.0 wieder auf unserem DEV Kafka zu installieren.

----------------- temporäre Umgehungslösung ---

In cloudera Manager 5.10 gibt es eine super.users Eigenschaft in der kafka Konfiguration. Das Hinzufügen von ANONYMOUS zu dieser Liste erlaubte mir, von meinen Themen zu produzieren und zu konsumieren.

Ich hatte bereits versucht, dies in /opt/cloudera/parcels/KAFKA-2.1.0-1.2.1.0.p0.115/etc/kafka/conf.dist/server.properties, die keine Wirkung hatte. Also muss Cloudera diese Werte anderswo verwalten.

Answer 1

Kafka unterscheidet streng zwischen Authentifizierung und Autorisierung - auch wenn Sie die Authentifizierung über Curb oder SSL gedreht davon haben, ist nach wie vor möglich Ermächtigung zum Einschalten über den folgenden Parameter:

authorizer.class.name=kafka.security.auth.SimpleAclAuthorize‌​r 

Dies wird Kafka überprüfen machen ACLs für Jeder Zugriff - da die Authentifizierung in Ihrem Fall jedoch deaktiviert ist, wird jeder Benutzer als ANONYMOUS ausgewertet und abgelehnt, wenn für diesen Benutzer keine ACLs festgelegt sind.

Sie können diese Einstellung aus Ihrer Konfiguration löschen, die Kafka zu seinem alten, vertrauenden Selbst zurückkehren lassen sollte. Ich bin nicht sicher, wo Sie dies in Cloudera Manager tun würden, so eine Alternative wäre, ANONYMOUS zu der Liste der Super-Benutzer hinzuzufügen, die in CM verfügbar ist. Oder definieren Sie einfach eine ACL, um den Zugriff auf ANONYMOUS zu ermöglichen.

Für spätere Produktionszwecke sollten Sie wahrscheinlich entweder SSL oder Kerberos einrichten und geeignete ACLs definieren, wenn die Möglichkeit besteht, dass auf den Cluster von außen zugegriffen wird.