Блог

У меня ужасные проблемы с ACL авторизации в Kafka 2.6. У меня настроен TLS, и он отлично работает между моим клиентским приложением и всеми узлами kafka. У меня есть свойства acl в файле server.properties

 #TLS Portion
advertised.listeners=SSL://10.1.1.2:9092
listeners=SSL://:9092
ssl.keystore.location=/opt/kafka/keystore.jks
ssl.keystore.password=password
ssl.key.password=password
ssl.truststore.location=/opt/kafka/truststore.jks
ssl.truststore.password=password
ssl.enabled.protocols=TLSv1.2
ssl.client.auth=required
security.inter.broker.protocol=SSL
security.protocol=SSL

#ACL Portion
authorizer.class.name=kafka.security.authorizer.AclAuthorizer
allow.everyone.if.no.acl.found=false
super.users=User:CN=me@me.me
  

У меня включена ОТЛАДКА для журналов авторизации. Если я установлю для параметра allow.everyone~ значение true, это сработает, потому что я полагаю, что он перестает беспокоиться об авторизации / ACL, и в настоящее время значение super.users используется для моего клиентского приложения и отлично работает для сообщений ОТЛАДКИ.

Когда я запускаю службу на каждом узле, я получаю ClusterAction not allowed, когда узел выглядит так, как будто они пытаются запросить UpdateMetadata друг у друга.

Я применил запись ACL, предполагая, что сервер CN=server.side

 bin/kafka-acls.sh --authorizer kafka.security.authorizer.AclAuthorizer --authorizer-properties zookeeper.connect=10.1.1.5:2181 --add --allow-principal User:CN=server.side  --operation ClusterAction --cluster sample-cluster
  

на всех узлах нет кубиков.

Я пытаюсь установить с --operation ALL помощью, и это не сработало. Я также пытаюсь вместо этого указать команду на узел --bootstrap-server , и это вообще ничего не возвращает, и я могу получить ошибку тайм-аута (я предполагаю, что он принимает запись ACL, но затем не может распространить ее на другие узлы из-за вышеупомянутой проблемы).

Я прошел через добавление ACL для тем, потребителей и производителей различной схемы разрешений, но, похоже, это происходит только при запуске, когда узел пытается перекрестно обмениваться данными. В результате я получаю пользователей и производителей клиентских приложений, которые могут подключаться, авторизоваться в своих соответствующих темах, но затем не возникают проблемы с метаданными ЛИДЕРА.

Я был в Google весь день; кто-нибудь знаком с этим? TIA

Согласно документации Confluent при авторизации.

Каждый брокер должен иметь возможность взаимодействовать со всеми другими брокерами для репликации и когда он действует как контроллер. Вы должны добавить участника-брокера в качестве суперпользователя, иначе Kafka не будет работать.

Также

В защищенном кластере авторизация требуется как для клиентских запросов, так и для операций между брокерами. Операции между брокерами разделены на два класса: кластерные и тематические. Операции кластера относятся к операциям, необходимым для управления кластером, таким как обновление метаданных брокера и раздела, изменение лидера и набора синхронизированных реплик раздела и запуск контролируемого завершения работы.

Из-за того, что репликация тематических разделов работает внутри, участник брокера должен быть суперпользователем, чтобы брокер мог правильно реплицировать темы от лидера к последователю.

Итак, вы должны добавить в список своих участников-брокеров. super.users Кстати, вы можете настроить ssl.principal.mapping.rules извлечение основного имени таким образом, чтобы оно не содержало CN= часть. Например: подобное правило RULE:^CN=(.*?)$/$1/ даст вам подобное принципалу me@me.me .