【问题标题】:Kafka on Cloudera - test=TOPIC_AUTHORIZATION_FAILEDCloudera 上的 Kafka - test=TOPIC_AUTHORIZATION_FAILED
【发布时间】:2017-03-06 21:14:11
【问题描述】:

我们刚刚从 CDH 5.3.6 升级到 5.10.0,在尝试写入 Kafka 主题时开始出现错误。我们对所有东西都有默认设置,没有启用 SSL 或 Kerberos 身份验证。当使用控制台生产者写入我的一个主题时,我收到此错误:

/usr/bin/kafka-console-producer --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}

查看/var/log/kafka/,我看到了一堆这样的异常:

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)

我一直在寻找解决此问题的方法,但到目前为止还没有找到。我是否需要将匿名用户分配给某处的某些组?我能够在 CDH 5.3.6 中向我的主题写入消息,但升级时似乎出现了问题。

只是想在升级到 CDH 5.10.0 后让 helloWorld/Quickstart 示例在我们的 DEV Kafka 上再次运行。

----------------- 临时变通解决方案---

在 cloudera manager 5.10 中,kafka 配置中有一个 super.users 属性。将 ANONYMOUS 添加到该列表中,使我能够从我的主题中生产和消费。

我已经尝试在 /opt/cloudera/parcels/KAFKA-2.1.0-1.2.1.0.p0.115/etc/kafka/conf.dist/server.properties 中执行此操作,但没有效果。所以 Cloudera 必须在其他地方管理这些值。

【问题讨论】:

  • 您能检查一下您为 authorizer.class.name 设置的值吗?当您没有配置 Kerberos 或 SSL 时,如果在此处设置了某些内容,您仍然可以强制执行 ACL,但每个连接的人都将被验证为“匿名”,这是您可以在日志中看到的。
  • 我修改了 /opt/cloudera/parcels/KAFKA-2.1.0-1.2.1.0.p0.115/etc/kafka/conf.dist/server.properties 有这一行:authorizer.class .name=kafka.security.auth.SimpleAclAuthorizer 但这似乎并不重要,我什至不确定这是否是正确的文件,或者如何验证更改是否生效。
  • 是的,里拉是造成这种情况的原因(不确定文件,但似乎合适)。通过该行,您告诉 Kafka 将 ACL 应用于所有连接尝试——所有这些都将反对“匿名”。我建议删除那条线,一切都应该工作。或者,您可以在配置中将 ANONYMOUS 设置为超级用户,这应该具有相同的效果,但不提供任何额外的安全性,因此在 imo 中并不是真正有用。
  • 可悲的是,在我添加该行之前,升级后就开始发生此错误。我已经删除了它,它仍然在发生。除了 server.properties 文件之外,它可以配置在其他地方吗?我在 Cloudera Manager 中的任何地方都没有看到它。
  • 不确定设置是否在CM中,我手头没有集群可以检查。我认为有一个选项可以在某处添加超级用户,如果在不检查 Kerberos 身份验证的情况下启用该选项,可以尝试在此处添加匿名作为解决方法。

标签: apache-kafka apache-zookeeper cloudera cloudera-cdh apache-sentry


【解决方案1】:

Kafka 严格区分身份验证和授权 - 即使您通过 Curb 或 SSL 进行身份验证,仍然可以通过以下参数打开授权:

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

这将使 Kafka 检查每次访问的 ACL - 因为在您的情况下已关闭身份验证,如果没有为该用户设置 ACL,则每个用户都将被评估为 ANONYMOUS 并被拒绝。

您可以从配置中删除该设置,这将使 Kafka 恢复其旧的、信任的自我。我不确定您会在 Cloudera Manager 中的哪个位置执行此操作,因此另一种方法是将 ANONYMOUS 添加到 CM 中可用的超级用户列表中。或者当然只是定义一个 ACL 以允许访问 ANONYMOUS

如果以后有可能从外部访问集群,您可能应该设置 SSL 或 Kerberos,并定义适当的 ACL。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2019-11-24
    相关资源
    最近更新 更多