Kafka: Часть 10 — Межброкерное (inter-broker) взаимодействие с SASL_SSL PLAIN и ACL

DRAFT

В предыдущей статье мы рассмотрели права ACL и попробовали ими управлять. В этой статье мы добавим настройки для межброкерного взаимодействия.

А если хотите узнать зачем вообще нужна межброкерная коммуникация в Kafka с одним сервером, то Вам сюда.

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

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

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

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

 

Настройка межброкерного взаимодействия

Итак, из предыдущих статей мы знаем, что межброкерное взаимодействие у нас по умолчанию незащищенное. Т.е. как PLAINTEXT. И, если мы добавляем для клиентов аутентификацию по другому протоколу, то должны оставить явно PLAINTEXT помимо клиентского соединения. Это мы все время и делали. У нас всегда было описано два соединения:

  1. SASL_SSL://localhost:9093 — на 9093 порту мы описывали соединения для наших экспериментов с клиентом. И потом описывали выбор протокола для клиента с помощью опции security.protocol.
  2. PLAINTEXT://localhost:9092 — а это соединение мы оставили для межброкерного взаимодействия. Выбор именно этого соединения для межброкерного взаимодействия мы явно не задавали. Потому как PLAINTEXT выбирается по умолчанию.

Что же это за межброкерное взаимодействие? Это обмен информацией между серверами Kafka и некоторые сервисные операции.

Как же выбрать для межброкерного взаимодействия не PLAINTEXT, а другое? Например то же SASL_SSL? Для этого есть аналоги опций security.protocol и sasl.enabled.mechanisms:

  1. security.inter.broker.protocol — делает то же, что и security.protocol, только для межброкерного взаимодействия.  Т.е. выбирает протокол.
  2. sasl.mechanism.inter.broker.protocol — делает то же, что и sasl.enabled.mechanisms, только для межброкерного взаимодействия. Т.е. выбирает конкретный механизм аутентификации SASL.

Т.е. в строках advertised.listeners и listeners мы описываем все типы протоколов. А дальше опциями выбираем какой из описанных протоколов будет работать для клиентов, а какой для межброкерного взаимодействия. При этом настройки авторизации будут работать для всех соединений! Давайте возьмем пример из 8-ой статьи. Там у нас была аутентификация клиента по протоколу SASL_SSL с механизмом PLAIN и авторизацией. И сделаем так, чтобы межброкерное взаимодействие так же шло через 9093 порт по протоколу SASL_SSL. Для этого мы уберем PLAINTEXT описание из соединений. Тогда соединения у нас станут такими:

И для межброкерного взаимодействия выберем SASL_SSL

Почти все! Осталась одна важная деталь!

Поскольку у нас соединение SSL то нужно предоставить еще и хранилище доверенных сертификатов для сервера. Ведь должны же брокеры проверять сертификаты друг-друга как-то.

Для этого возьмем наш сертификат сервера, который мы делали в этой статье, и создадим с ним хранилище для сервера:

Где domain.pem — сертификат сервера (он либо Вам выдан, либо вы его создавали в этой статье). После выполнения операции появится файл server.truststore.jks. Также запомните пароль к хранилищу.

Добавим наше хранилище доверенных сертификатов к настройкам сервера:

Не забудьте сделать владельцем хранилища пользователя kafka!

Теперь последний штрих. Поскольку брокеры у нас теперь полноценно аутентифицируются, то можно убрать опцию ACL:

И нужно добавить сделать пользователя, с помощью которого общаются брокеры, суперпользователем:

Давайте посмотрим на наш полный конфиг сервера Kafka:

Отлично, теперь запустим Kafka! Клиент править нет необходимости. Его также берем из 8-ой статьи и запускаем. Вывод должен быть:

Проверка работы ACL

Резюме

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

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