Обзор аутентификации Kafka

Безопасность Kafka — не опция для production-кластеров. Это обязательный слой, без которого любой процесс в сети может читать ваши данные, записывать мусор в топики и уничтожить конфигурацию кластера. В Kafka 4.0 с KRaft безопасность настраивается через конфигурацию брокера — ZooKeeper полностью удалён, и вместе с ним ушло старое ZooKeeper-хранилище ACL.

Модуль 09 охватывает все три уровня безопасности:

• Аутентификация (authentication): кто вы? Доказательство идентичности клиента.
• Авторизация (authorization): что вам можно? ACL определяют разрешённые операции.
• Шифрование (encryption): защита данных в пути. TLS предотвращает перехват трафика.

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

Security Protocol: четыре варианта

Каждый listener в Kafka broker работает с одним из четырёх security protocol. Protocol определяет, есть ли шифрование и аутентификация на этом listener.

Listeners и security.protocol: брокер на нескольких портах

Kafka broker может обслуживать разные протоколы на разных портах одновременно. Это позволяет, например, обслуживать внутренние сервисы через SASL_PLAINTEXT (доверенная сеть, без overhead TLS), а внешних клиентов — через SASL_SSL.

# Объявить listeners: имя, протокол, порт
listeners=INTERNAL://0.0.0.0:9092,EXTERNAL://0.0.0.0:9094

# Сопоставить имена listeners с security protocol
listener.security.protocol.map=INTERNAL:SASL_PLAINTEXT,EXTERNAL:SASL_SSL

# Advertised listeners (для клиентов: hostname, не 0.0.0.0)
advertised.listeners=INTERNAL://broker1.internal:9092,EXTERNAL://broker1.example.com:9094

# Inter-broker listener (для репликации между брокерами)
inter.broker.listener.name=INTERNAL

SASL-механизмы: обзор четырёх вариантов

SASL (Simple Authentication and Security Layer) — протокол-фреймворк, который позволяет выбрать механизм аутентификации независимо от транспорта. Kafka поддерживает четыре SASL-механизма, каждый со своими компромиссами.

SASL/PLAIN

Простейший механизм. Username и password отправляются в base64-кодировке (это НЕ шифрование — base64 тривиально декодируется). Credentials хранятся статически в JAAS config файле брокера.

# Broker JAAS config (в server.properties или отдельный файл)
listener.name.sasl_ssl.plain.sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \
  username="admin" password="admin-secret" \
  user_admin="admin-secret" \
  user_producer="producer-secret" \
  user_consumer="consumer-secret";

Каждый user_<name>="<password>" определяет допустимого пользователя. Добавление нового пользователя требует изменения конфига и перезапуска брокера.

SASL/SCRAM

Salted Challenge-Response: клиент и сервер выполняют challenge-response обмен, в результате которого сервер убеждается, что клиент знает пароль — без передачи самого пароля по сети. Credentials хранятся в KRaft metadata log в виде salted hash.

# Создать пользователя (работает без перезапуска брокера)
kafka-configs.sh --bootstrap-server localhost:9092 \
  --alter \
  --add-config 'SCRAM-SHA-256=[iterations=8192,password=alice-secret]' \
  --entity-type users --entity-name alice

SASL/OAUTHBEARER

Клиент получает JWT token от IdP (Identity Provider) и предъявляет его брокеру. Брокер валидирует подпись JWT через JWKS endpoint IdP. Kafka 4.0 включает встроенный OAuthBearerLoginCallbackHandler и OAuthBearerValidatorCallbackHandler — не нужен кастомный код для стандартного client_credentials flow.

SASL/GSSAPI (Kerberos)

Enterprise SSO через Kerberos. Клиент использует keytab для получения Ticket Granting Ticket (TGT) от KDC, затем Service Ticket для Kafka. Реализует SSO с Active Directory. Самый сложный в настройке, требует Kerberos инфраструктуры.

Дерево принятия решений: когда какой механизм

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

Inter-broker security

Брокеры Kafka реплицируют данные друг другу — это тоже сетевой трафик, который нужно защищать. В KRaft кластере контроллеры обмениваются метаданными через отдельный controller listener.

# Протокол для inter-broker репликации
security.inter.broker.protocol=SASL_SSL

# SASL-механизм для inter-broker коммуникации
sasl.mechanism.inter.broker.protocol=SCRAM-SHA-256

# JAAS для inter-broker: брокер аутентифицируется как 'kafka-broker'
listener.name.internal.scram-sha-256.sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required \
  username="kafka-broker" password="broker-secret";

В Kafka 4.0 KRaft: controller listener (порт для Raft consensus) обычно в изолированной сети и может использовать PLAINTEXT или отдельный SASL механизм. Клиенты никогда не подключаются к controller listener напрямую.

Ключевые выводы

1. Kafka security имеет три уровня: аутентификация (кто вы?), авторизация (что можно?), шифрование (защита в пути).
2. Четыре security protocol: PLAINTEXT (dev), SSL (шифрование + опциональный mTLS), SASL_PLAINTEXT (SASL без TLS), SASL_SSL (production standard).
3. Broker может обслуживать несколько listeners с разными протоколами на разных портах.
4. SASL/PLAIN — только для dev и только с SSL. SASL/SCRAM — оптимальный production выбор. SASL/OAUTHBEARER — для сред с IdP. SASL/GSSAPI — для Kerberos enterprise.
5. Inter-broker коммуникация тоже требует security-конфигурации.