Kafka: Часть 8 — Аутентификация и авторизация с ACL

В предыдущей статье мы настроили и проверили аутентификацию по протоколу SASL с механизмом PLAIN через SSL. Настало время познакомиться с авторизацией в Kafka!

Предыдущая статья. Следующая статья.

Полный список статей по теме тут.

Заходите в наш телеграмм канал — Enterprise Stack Helper! Делитесь опытом или задавайте вопросы, если что-то непонятно.

Репозитории с примерам из статей по способам аутентификаци и авторизации https://github.com/BlockWit/kafka-security-examples.

 

ACL в Kafka

Давайте вспомним основную информацию из первой статьи:

  1. Авторизация — это процесс проверки — имеет ли право пользователь выполнять те или иные действия над ресурсом
  2. Авторизация настраивается независимо от аутентификации
  3. Авторизация, если она настроена, выполняется после аутентификации
  4. Kafka имеет встроенный авторизатор на базе ACL

А теперь подробнее о некоторых пунктах.

Авторизация настраивается независимо от аутентификации. Т.е. независимо от любой схемы аутентификации мы можем добавить конфигурацию авторизации на сервер и она будет работать.

Kafka имеет встроенный авторизатор на базе ACL. ACL — это просто списки,  в которых описано кому над каким ресурсом можно совершать действия.

Авторизатор включается так:

Еще нужно добавить опцию:

Что она означает? Она делает вот что:

  1. Если топик, группа или другой объект не имеют ни одной записи в списке ACL, то доступ к этому топику, группе или другому объекту разрешен для всех!
  2. Если топик, группа или другой объект имеет хотя бы одну ACL запись, то доступ к этому топику, группе или объекту разрешен тем, у кого есть соответствующие права, и суперпользователям.

Если allow.everyone.if.no.acl.found=false, то:

  1. Если топик, группа или другой объект не имеют ни одной записи в списке ACL, то доступ к этому топику, группе или другому объекту разрешен только суперпользователям.
  2. Если топик, группа или другой объект имеет хотя бы одну ACL запись, то доступ к этому топику, группе или объекту разрешен тем, у кого есть соответствующие права, и суперпользователям.

Зачем же мы установили allow.everyone.if.no.acl.found в true? Логичным было бы запретить доступ ко всем топикам, если у пользователя нет прав. Это сделано сейчас для удобства, чтобы мы могли быстро настроить ACL.

Дело в том, что у нас есть межброкерное взаимодействие на 9092 порту. Для сервсных операций Kafka. (Подробнее в  в этой статьей). И на 9092 порту нет аутентификации.  Это значит, что сервер не сможет определить «личность» клиента. А значит и не сможет провести авторизацию по ACL! Ведь ACL авторизатор работает для всех соединений сразу. В итоге клиент на 9092 порту не получит вообще никаких прав. А это значит, что Kafka не сможет выполнять сервисные операции. И работать наш сервер корректно не будет. А в логах сможем увидеть такую ошибку:

Сервисные операции касаются конфигурации самой Kafka (конфигурации кластера, если быть точным). Поскольку мы им не указывали списки доступа ACL, то мы можем поставить опцию — allow.everyone.if.no.acl.found в true. Таким образом, неаутентифицированный сервисный клиент получит возможность выполнять ВСЕ операции над конфигурацией Kafka. Таким образом, межброкерное взаимодействие будет работать корректно.

Безусловно, такой подход — дыра в безопасности. И мы ее исправим в ближайших статьях, когда будем настраивать аутентификацию для межброкерного взаимодействия. А пока поработаем с этой опцией.

С конфигурационным файлом сервера все. Однако нам нужно теперь сконфигурировать сами списки ACL.

В этом нам помогут команды:

  • Просмотр списков ACL для топика [TOPICNAME]
  • Разрешить пользователю [USERNAME]  выполнять операцию [OPERATION] над топиком [TOPICNAME]
  • Запретить пользователю [USERNAME]  выполнять операцию [OPERATION] над топиком [TOPICNAME]

Обратите внимание, что в командах указывается соединение с ZooKeeper. Дело в том, что Kafka хранит списки ACL в ZooKeeper.

Теперь давайте приступим к практике.

Авторизация ACL с SASL_SSL и PLAIN

Для начала запустим Kafka и добавим в списки ACL право Алисе (у нас она alice) выполнять любые действия (обозначается как ALL) над топиком stats.store.

После выполнения команды Kafka даст нам знать, что права изменены:

Отлично. Теперь скопируем конфигурацию SASL_SSL+PLAIN для сервера из предыдущей статьи. И добавим к ней конфигурацию авторизатора. Приведем полную конфигурацию:

Не забывайте менять localhost, ssl.keystore.location и ssl.keystore.password на свои!

Настройки клиента остаются такие же, как и в предыдущей статье.

Не забывайте менять localhost, ssl.truststore.location и ssl.truststore.password на свои!

Запустим Kafka, потом клиент и получим вывод успешной отправки сообщений:

Резюме

В этой статье мы узнали, как добавлять авторизацию ACL к любой схеме аутентификации в Kafka. 

В следующей статье мы рассмотрим права ACL в Kafka более детально.

Предыдущая статья. Следующая статья.

Полный список статей по теме тут.

Заходите в наш телеграмм канал — Enterprise Stack Helper! Делитесь опытом или задавайте вопросы, если что-то непонятно.

Репозитории с примерам из статей по способам аутентификаци и авторизации https://github.com/BlockWit/kafka-security-examples.

 

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *