Плагин Kafka ищет топики, группы потребителей, транзакционные ID, пользователей SCRAM и токены делегирования и управляет политиками доступа в терминах самой Kafka: её типы ресурсов служат уровнями ресурсов, а операции ACL — типами доступа. ID плагина и тип сервиса — kafka. Плагин сервиса работает на сервере GrantForge; агент Kafka, установленный в брокерах и контроллерах, применяет политики.
Интеграционные тесты Testcontainers в репозитории покрывают Kafka 3.7.2, 3.9.2, 4.1.2 и 4.3.1 со входом через SASL PLAIN и SCRAM и собственным авторизатором Kafka, а также Kerberos (keytab и пароль) и TLS на 4.3.1; это не сертифицирует все остальные версии.
Установка
Дистрибутив содержит плагин в plugins/kafka. Убедитесь, что kafka включён в Управление платформой → Плагины; после обновления каталога плагинов просканируйте его заново. Плагин общается с брокерами через собственный клиент Admin Kafka (kafka-clients 4.3.1) в отдельном загрузчике классов.
Добавление сервиса данных
- Откройте Права на данные → Сервисы данных, добавьте сервис и выберите Apache Kafka (
kafka). - Укажите серверы начальной загрузки и способ защиты слушателя брокеров.
- Укажите пользователя для поиска, проверьте подключение и сохраните сервис. Проверка входит в систему и описывает кластер: его ID и число брокеров.
Параметры носят имена клиентов Kafka, поэтому их можно скопировать из конфигурации клиента. Пользователь для поиска позволяет GrantForge находить ресурсы; он не связан с клиентами, которые производят и потребляют сообщения. Успешная проверка подключения не означает, что запросы уже подчиняются политикам.
| Параметр | Назначение |
|---|---|
bootstrap.servers |
Обязательные начальные брокеры, хост:порт через запятую, например kafka1:9092,kafka2:9092 |
security.protocol |
PLAINTEXT (по умолчанию), SSL, SASL_PLAINTEXT или SASL_SSL |
sasl.mechanism |
Только для протоколов SASL: PLAIN, SCRAM-SHA-256 или SCRAM-SHA-512 с паролем, GSSAPI для Kerberos |
username |
SASL: пользователь для поиска; при Kerberos — полный принципал, например grantforge@EXAMPLE.COM |
password |
Пароль пользователя или, без keytab, пароль Kerberos принципала; хранится в зашифрованном виде |
keytab |
Kerberos: путь к keytab принципала, доступный для чтения на сервере GrantForge |
kerberos.kdc |
Kerberos: KDC области принципала, хост[:порт] через запятую; пустое значение использует krb5.conf сервера |
sasl.kerberos.service.name |
Kerberos: первая часть принципалов брокеров, по умолчанию kafka |
ssl.truststore.location, ssl.truststore.password, ssl.truststore.type |
TLS: хранилище доверенных сертификатов для проверки брокеров (JKS, PKCS12 или PEM); пустое значение доверяет тому, чему доверяет Java |
ssl.keystore.location, ssl.keystore.password, ssl.key.password |
TLS: сертификат GrantForge для брокеров, которые требуют его от клиентов |
ssl.verify.hostname |
TLS: должны ли сертификаты брокеров называть хосты подключения, по умолчанию true |
request.timeout.ms |
Тайм-аут запросов, по умолчанию 30000, диапазон 1..600000 |
Параметры SASL отклоняются при PLAINTEXT и SSL, параметры TLS — при PLAINTEXT и SASL_PLAINTEXT. PLAIN и SCRAM требуют пароль; GSSAPI требует пароль или keytab.
Kerberos
При GSSAPI GrantForge выполняет вход принципала через собственный вход Kerberos Kafka, по keytab или с паролем, который GrantForge передаёт входу сам; больше ничего на сервере GrantForge не требует настроек Kerberos. Области, KDC которых указаны в kerberos.kdc, объявляются для всего сервера GrantForge, как это делают плагины HDFS и Hive, поэтому разные сервисы могут одновременно использовать разные области.
Что видит пользователь для поиска
Kafka показывает пользователю только то, что он может описать, поэтому пользователю для поиска нужен describe на топиках, группах и транзакционных ID, которые он должен предлагать, и describe на кластере для пользователей SCRAM. Kafka пропускает топики и группы, которые он не может описать, поэтому подсказки оказываются пустыми, а не отклонёнными. Внутренние топики, например __consumer_offsets, предлагаются, когда введённый текст начинается с _. Кластер без токенов делегирования или без SCRAM их не предлагает.
Когда агент Kafka применяет политики, они решают и то, что может описывать пользователь для поиска: дайте ему политику, разрешающую describe, или укажите его в super.users брокеров.
Ресурсы и типы доступа
| Уровень | Ресурс Kafka | Типы доступа |
|---|---|---|
topic |
Топики | read, write, create, delete, alter, describe, describe_configs, alter_configs, all |
group |
Группы потребителей | read, delete, describe, all |
transactional_id |
Транзакционные ID | write, describe, all |
cluster |
Кластер, всегда называемый kafka-cluster |
create, alter, describe, cluster_action, describe_configs, alter_configs, idempotent_write, all |
delegation_token |
Токены делегирования, по ID токена | describe, all |
user |
Пользователи, чьи токены делегирования создаются или описываются | create_tokens, describe_tokens, all |
Каждый уровень самостоятелен; политика называет один. Значения чувствительны к регистру: * соответствует любому числу символов, ? — одному. Типы доступа подразумевают другие так же, как операции ACL Kafka: read, write, delete и alter подразумевают describe, alter_configs подразумевает describe_configs, а all — все остальные.
Подразумевание действует и для запретов: политика, запрещающая write на топике, запрещает и describe, который подразумевает write, поэтому пользователь перестаёт видеть топик. Собственные ACL Kafka применяют подразумевание только к разрешённым операциям.
Редактор политик предлагает имена из кластера по префиксу; для cluster он предлагает kafka-cluster.
Пример политик
Допустим, продюсеры пользователя alice пишут в топики, имена которых начинаются с orders, а группа analysts читает их с группой потребителей billing. Создайте в одном сервисе данных три включённые политики доступа:
| Ресурсы | Правило |
|---|---|
topic=orders* |
Разрешить write пользователю alice |
topic=orders* |
Разрешить read группе analysts |
group=billing |
Разрешить read группе analysts |
Когда агент применит новый снимок, alice сможет писать в orders-eu, в том числе идемпотентным продюсером и без idempotent_write на кластере; участники analysts будут потреблять его как billing; другие топики и группы откажут обоим. kafka-acls --list покажет три политики как ACL с префиксом и литеральные ACL.
Применение политик
Плагин сервиса управляет политиками и ищет ресурсы. Чтобы применять их, в каждом брокере и контроллере нужен агент Kafka. Развёртывание и проверки описаны на странице агента Kafka.