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

Аутентификация отвечает на вопрос “кто вы?”. Авторизация отвечает на вопрос “что вам разрешено?”. В Kafka авторизация реализована через ACL (Access Control Lists) — явные правила, определяющие, какой principal может выполнять какие операции с какими ресурсами.

Authorizer в Kafka 4.0 (KRaft)

В Kafka 4.0 используется StandardAuthorizer — KRaft-нативный authorizer. Его предшественник AclAuthorizer хранил ACL в ZooKeeper и полностью удалён вместе с ZooKeeper.

# ВАЖНО: только StandardAuthorizer в Kafka 4.0
# AclAuthorizer (kafka.security.authorizer.AclAuthorizer) — УДАЛЁН
authorizer.class.name=org.apache.kafka.metadata.authorizer.StandardAuthorizer

# Deny by default: если для операции нет ACL — ЗАПРЕТ
allow.everyone.if.no.acl.found=false

# Super users: обходят все ACL-проверки
super.users=User:admin;User:kafka-controller

# Разрешить старт брокера до загрузки всех ACL из metadata log
early.start.listeners=CONTROLLER

ACL в Kafka 4.0 хранятся в __cluster_metadata internal topic (KRaft log контроллера). Изменения ACL применяются через kafka-acls.sh и реплицируются на все брокеры через KRaft consensus.

ACL Resource Hierarchy

Диаграмма выше показывает иерархию ресурсов и матрицу операций. Каждый ACL определяет: principal (кому), operation (что разрешено), resource type + name (на каком ресурсе), permission type (ALLOW или DENY).

Resource Types: пять типов ресурсов

Topic

Самый частый тип. ACL на топик контролирует produce и consume.

Group

Consumer Group ACL контролирует участие в consumer group.

Cluster

Cluster-level операции: AdminClient действия и inter-broker.

TransactionalId

Transactional producer использует transactional.id для гарантии exactly-once. ACL на TransactionalId контролирует, кто может использовать конкретный transactional.id.

Write on TransactionalId: инициализировать транзакцию (initTransactions)
Describe on TransactionalId: описать транзакционное состояние

DelegationToken

Delegation tokens позволяют сервисам делегировать аутентификацию другим компонентам без передачи credentials.

PatternType: LITERAL vs PREFIXED

PatternType определяет, как имя ресурса в ACL сопоставляется с реальными ресурсами.

kafka-acls.sh: команды

Выдать права producer

# Producer: Write + Describe на топик (минимум для produce)
kafka-acls.sh --bootstrap-server localhost:9092 \
  --command-config admin.properties \
  --add \
  --allow-principal User:producer-app \
  --operation Write \
  --operation Describe \
  --topic orders

Выдать права consumer

# Consumer: Read на топик + Read на consumer group
kafka-acls.sh --bootstrap-server localhost:9092 \
  --command-config admin.properties \
  --add \
  --allow-principal User:consumer-app \
  --operation Read \
  --operation Describe \
  --topic orders

kafka-acls.sh --bootstrap-server localhost:9092 \
  --command-config admin.properties \
  --add \
  --allow-principal User:consumer-app \
  --operation Read \
  --group consumer-group-1

Transactional producer (минимальный набор ACL)

# 1. Write + Describe на топик
kafka-acls.sh --add --allow-principal User:txn-producer \
  --operation Write --operation Describe --topic orders

# 2. Write на TransactionalId
kafka-acls.sh --add --allow-principal User:txn-producer \
  --operation Write \
  --transactional-id txn-orders

# 3. Idempotent write на кластере
kafka-acls.sh --add --allow-principal User:txn-producer \
  --operation IdempotentWrite \
  --cluster

# Если consumer group тоже нужна (transactional consumer):
kafka-acls.sh --add --allow-principal User:txn-producer \
  --operation Read --group txn-group

PREFIXED ACL для service namespace

# Payments service: все топики с prefix 'payments.'
kafka-acls.sh --bootstrap-server localhost:9092 \
  --add \
  --allow-principal User:payments-svc \
  --operation Write --operation Read --operation Describe \
  --topic 'payments.' \
  --resource-pattern-type prefixed

# Payments service: все consumer groups с prefix 'payments-'
kafka-acls.sh --bootstrap-server localhost:9092 \
  --add \
  --allow-principal User:payments-svc \
  --operation Read \
  --group 'payments-' \
  --resource-pattern-type prefixed

Просмотр и удаление ACL

# Список всех ACL на топик 'orders'
kafka-acls.sh --bootstrap-server localhost:9092 \
  --command-config admin.properties \
  --list --topic orders

# Список всех ACL в кластере
kafka-acls.sh --bootstrap-server localhost:9092 \
  --command-config admin.properties \
  --list

# Удалить ACL
kafka-acls.sh --bootstrap-server localhost:9092 \
  --remove \
  --allow-principal User:old-producer \
  --operation Write --topic orders

ACL-стратегия для production

Namespace-based подход

Каждый сервис владеет namespace (prefix) для своих ресурсов. Payments service создаёт топики payments.transactions, payments.refunds, payments.events — и получает PREFIXED ACL на payments..

Сервис            Prefix          ACL pattern type
payments-svc    → payments.     → PREFIXED Write на Topic
orders-svc      → orders.       → PREFIXED Write на Topic
notifications   → notify.       → PREFIXED Write на Topic

Преимущества:

• Один ACL вместо N ACL при добавлении нового топика.
• Сервис не может случайно записать в чужой namespace.
• Понятная модель ownership.

Принцип минимальных привилегий

Отдельные principals для каждого приложения — никогда не делите credentials между сервисами. Если сервис A скомпрометирован — только его credentials отзываются, остальные в безопасности.

Deny ACL для инцидент-реагирования

# Немедленно заблокировать скомпрометированный сервис
kafka-acls.sh --add \
  --deny-principal User:compromised-app \
  --operation All \
  --topic '*' \
  --resource-pattern-type prefixed \
  --group '*' \
  --resource-pattern-type prefixed

DENY ACL имеет приоритет над ALLOW ACL — даже если у principal есть разрешающее правило, DENY перекрывает его.

ACL и SASL principal mapping

Как Kafka формирует principal из SASL аутентификации:

Для OAUTHBEARER можно настроить, какой JWT claim использовать как principal:

# Использовать claim 'preferred_username' вместо 'sub'
sasl.oauthbearer.sub.claim.name=preferred_username

Для полной кастомизации — principal.builder.class с реализацией KafkaPrincipalBuilder.

Типичные ошибки с ACL

Consumer не может consume из топика:

• Забыли Group:Read ACL (consumer не может join/commit в consumer group).
• Забыли Topic:Describe (metadata refresh failing).

Transactional producer получает ошибку:

• Забыли Cluster:IdempotentWrite.
• Забыли TransactionalId:Write.

Service создаёт топики через AdminClient:

• Нужен Cluster:Create (не Topic:Create).

PREFIXED ACL не работает:

• Убедитесь, что указали --resource-pattern-type prefixed в kafka-acls.sh.
• По умолчанию тип LITERAL — при отсутствии флага создаётся LITERAL ACL.

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

1. Kafka 4.0 использует StandardAuthorizer — ACL в KRaft metadata log. AclAuthorizer удалён.
2. allow.everyone.if.no.acl.found=false — обязательно в production. Deny by default.
3. Consumer minimum: Topic:Read + Topic:Describe + Group:Read. Producer minimum: Topic:Write + Topic:Describe.
4. Transactional producer дополнительно: TransactionalId:Write + Cluster:IdempotentWrite.
5. PREFIXED ACL для service namespace ownership — один ACL для всех топиков сервиса.
6. DENY ACL для инцидент-реагирования: перекрывает ALLOW ACL.