Моя настройка следующая:
- 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.