Кафка: Установить ACL для нескольких пользователей, когда zookeeper.set.acl = true? - PullRequest
0 голосов
/ 26 сентября 2019

Моя настройка следующая:

  • 3 узла Zookeeper защищены следующим образом:
    • SASL включен (quorum.auth.enableSasl = true)
    • Требуется SASL для учащихся (ученикRequireSasl = true)
    • Требуется SASL для серверов (quorum.auth.serverRequireSasl = true)
    • Требуется SASL для клиентов (requireClientAuthScheme = sasl)
    • AФайл jaas.conf с записями QuorumServer, QuorumLearner (оба с тем же zookeeper аккаунтом и паролем) и Сервером (с kafka плюс суперпользователь учетная запись, плюс пароли)

Идея учетной записи superuser заключается в том, что я могу использовать отдельные идентификационные данные и секреты (и, возможно, разрешения) для кластера Kafka в сравнении с соединениями администраторов из инструментов CLI.

Затем ...

  • 3 узла Kafka защищены следующим образом:
    • Все слушателитребуют SASL_PLAINTEXT (listener.security.protocol.map)
    • Механизмом SASL является SCRAM-SHA-512 (sasl.enabled.mechanisms)
    • Брокерам требуется SASL для межброкерских, а также клиентских соединений (sasl.mechanism.inter.broker.protocol)
    • Суперпользователи: kafka , суперпользователь
    • Установить ACL для всех метаданных, которые создает Кафка (zookeeper.set.acl = true).См. (KIP-38) (https://cwiki.apache.org/confluence/display/KAFKA/KIP-38%3A+ZooKeeper+Authentication)

В развертываниях Kafka + Zookeeper с настройками по умолчанию Zookeeper по существу не применяет никаких заслуживающих внимания механизмов защиты. Любой мошенник, который может подключиться кЭкземпляр Zookeeper (например, после проникновения в так называемую изолированную сеть) может по желанию изменять метаданные Kafka, хранящиеся в Zookeeper, такие как создание новых пользователей Kafka и повышение прав доступа.

С помощью zookeeper.set.acl =Значение true , Kafka автоматически применяет списки ACL ко всем создаваемым им Znodes (для кластеров, тем, смещений и т. д.), чтобы его Znodes были защищены от неавторизованного и неавторизованного доступа = больше защиты в глубину.

Важно : Эти списки ACL являются списками ACL Znode (концепция Zookeeper) и не совпадают с ACL Kafka, которые можно применять к кластерам, темам и т. П. zookeeper-shell.sh *В приведенном ниже примере 1065 * показаны подузлы / config и список ACL, заданный для / config / users Znode. kafka удостоверение имеет полный контроль, world не имеет никакого доступа:

ls /config
   [changes, clients, brokers, users, topics]
getAcl /config/users
   'sasl,'kafka
   : cdrwa

Kafka будет устанавливать ACL на Znodes только для одной учетной записи, которая обычно называется Кафка .Некоторые задачи администрирования Kafka, такие как добавление пользователей Kafka с аутентификацией SCRAM-SHA-512 (инструмент kafka-configs.sh), не могут быть выполнены через брокеров Kafka, но требуют прямого взаимодействия между инструментом CLI и Zookeeper.

Иэто, наконец, подводит меня к проблеме, с которой я сталкиваюсь: поскольку списки ACL Znode, автоматически устанавливаемые брокерами Kafka, устанавливаются только для идентификатора kafka , невозможно выполнять операции Zookeeper CLI с использованием любого другого идентификатора, такого как superuser identity.

Вопрос : Кто-нибудь знает, как заставить Kafka устанавливать Znode ACL для большего, чем просто kafka identity?В частности, мне также хотелось бы, чтобы удостоверение superuser могло вносить изменения непосредственно в Zookeeper.

...