Привет! Мы — команда сопровождения депозитарных систем Национального Расчетного Депозитария (НРД), входящего в Группу «Московская биржа».

Система электронного документооборота (ЭДО) НРД — ключевой элемент инфраструктуры финансового рынка, через неё проходит большинство критичных процессов. Осуществляется взаимодействие с клиентами и регистраторами, депонентами и эмитентами, финансовыми маркетплейсами, даже физические лица, когда запрашивают выписки из Регистратора финансовых транзакций (РФТ) делают это с помощью нашего ЭДО. Благодаря ему также работает Мультибанк НРД, решение для автоматизации корпоративного казначейства, обеспечивающее обмен финансовыми документами с банками через единый интерфейс и обрабатывающее около 47 миллионов документов в год.

Сердце нашей «ЭДОшной» системы — Arenadata Streaming ( Далее - ADS), российская платформа потоковых данных, созданная на базе Apache Kafka, прокачивающая 95% входящего и исходящего трафика компании, доставляя его до наших систем. И вот в этой жизненно важной системе Депозитария произошли глубинные изменения, затрагивающие саму архитектуру системы.

В статье расскажем об успешном кейсе внедрения продукта Kafka GitOps (в прошлой статье мы уже рассказывали про преимущества этого продукта) для автоматизации управления топиками и ACL в масштабах НРД.

В июле 2025 года наша команда успешно завершила проект по внедрению решения Kafka GitOps для автоматизации работы с топиками и управления списками доступов (ACL) в 24 независимых уникальных кластерах  ADS.

Идея проекта заключалась в переносе всех конфигураций топиков и ACL в корпоративный репозиторий Gitlab в виде YAML-файлов, что позволило перейти от ручного создания ресурсов к процессу, полностью контролируемому системой версионирования. При изменении файлов в корпоративном Gitlab план обновлений должен выполняться средствами AWX и доставляться в целевой кластер ADS. Важно заметить, для работы с ADS используются стандартные Kafka CLI, библиотеки и коннекторы. 

При каждом запуске инструмент Kafka GitOps сравнивает желаемое состояние кластера, описанное в файлах, с фактическим, и автоматически формирует план изменений. После применения плана топики и ACL соответствуют заданным параметрам, что существенно снижает риск ошибок и рассинхронизации.

Первой из трудностей, с которыми мы столкнулись, была выгрузка ACL с использованием нативных CLI-инструментов Apache Kafka.

Неструктурированный вывод команды kafka-acls.sh, который выводит информацию в специфичном текстовом формате, с переносами строк, отступами и описательными фразами.

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

Здесь нам на помощь пришел давно используемый инструмент Offset Explorer, который позволил выгрузить и экспортировать ACL в Excel.

В итоге мы получили удобный формат в виде столбцов с данными: Resource, Type, Resource, Name, Principal, Host, Operation, Permission Type, Pattern Type в разрезе всех контуров и кластеров ADS

Далее дело было за python скриптами и формированием YAML файла в виде:

services:
my-application1:
type: application
principal: User:myapp
group-id: my-application1
consumes:
- test-topic1
produces:
- test-topic1
my-application2:
type: application
principal: User:myapp2
group-id: my-application2
consumes:
- test-topic2
produces:
- test-topic2

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

Данный способ описания ролевой модели не покрывает некоторых случаев, к примеру, не позволяет задать права на чтение для одной учётной записи под несколькими group.id. Для таких случаев Kafka GitOps позволяет проводить тонкую настройку кастомных прав, например:

users:
gitops-user:
principal: User:gitops-user
customUserAcls:
gitops-user:
alter-cluster:
name: ads-cluster
type: CLUSTER
pattern: LITERAL
host: ""
operation: ALTER
permission: ALLOW
group-name1:
name: group-name1
principal: User: gitops-user
type: GROUP
pattern: LITERAL host: ""
operation: READ
permission: ALLOW

Здесь мы даём права ALTER пользователю gitops-user на кластер ads-cluster, а также производить чтение под группой group-name1.

 Далее мы перешли к декларированию списков топиков и их настроек. Тут мы обошлись нативным CLI-инструментом kafka-topics.sh + python скриптами для получения файла конфигурации вида:

settings:
  topics:
    defaults:
      replication: 4
topics:
  my-example-topic:
    partitions: 6
    replication: 1
    configs:
      cleanup.policy: compact
      retention.ms: 1209600000
      max.message.bytes: 2097176              

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

Наши требования были такими:
·       файлы конфигураций хранятся для каждого контура в своей директории
·       для каждого типа кластеров ADS в разрезе одного контура используется свой конфигурационный env, файл с топиками и ACL
·       топики и ACL ведутся в разных конфигурационных файлах
·       через GUI интерфейс AWX требуется сделать выбор кластера, требуемое действие и выбор опции только формировать план изменений (plan) или применить его (apply)
·       перед запуском плана изменений требуется провести валидацию конфигурационного файла (validate)

Примеры получившихся команд:

Для работы с топиками без ACL

КОНТУР -> ИМЯ_КЛАСТЕРА -> Добавить топик -> PLAN/APPLY:
java -jar /app/gitops/kafka-gitops.jar -f ПУТЬ ДО КОНФИГУРАЦИИ.yml --skip-acls --verbose validate
java -jar /app/gitops/kafka-gitops.jar -f ПУТЬ ДО КОНФИГУРАЦИИ.yml --skip-acls --no-delete --verbose (plan или apply)

 Для работы с ACL

КОНТУР -> ИМЯ_КЛАСТЕРА  -> Добавить ACL -> PLAN/APPLY:
java -jar /app/gitops/kafka-gitops.jar -f ПУТЬ ДО КОНФИГУРАЦИИ.yml --verbose validate
java -jar /app/gitops/kafka-gitops.jar -f ПУТЬ ДО КОНФИГУРАЦИИ.yml --no-delete --verbose (plan или apply)

 Примеры env конфигураций:

Для работы без ACL:

 KAFKA_BOOTSTRAP_SERVERS: 'kafka:9092'
  KAFKA_SECURITY_PROTOCOL: 'PLAINTEXT'

 Для работы c ACL:

 KAFKA_BOOTSTRAP_SERVERS: 'kafka-acl:9092'
  KAFKA_SECURITY_PROTOCOL: ''
  KAFKA_SASL_MECHANISM: ' '
  KAFKA_SASL_JAAS_USERNAME: 'gitops'
  KAFKA_SASL_JAAS_PASSWORD: 'ПАРОЛЬ'

 Основные итоги внедрения:

·       Все топики, их конфигурация и ACL описаны в YAML-файлах, хранящихся в централизованном корпоративном репозитории
·       На работу с Kafka GitOps переведены 24 уникальных независимых кластера ADS со своими уникальными конфигурациями
·       Версионные файлы позволяют легко отслеживать историю изменений, указывая причины и авторов правок, в отличие от ручных изменений через Kafka CLI
·       Полная непрерывная интеграция и доставка: при изменении файлов в корпоративном Gitlab план обновлений выполняется средствами AWX и доставляется в целевой кластер Kafka
·       Нет необходимости вручную создавать длинные команды для создания ACL в Kafka, вся логика генерируется автоматически
·       Централизованный контроль над топиками, учётными записями и доступами повышает прозрачность и безопасность инфраструктуры
·       Новые возможности для горизонтального масштабирования кластеров Kafka благодаря управлению replication factor

Новый подход к администрированию кластеров ADS позволил значительно ускорить развертывание топиков и обновление прав доступа, снизить число инцидентов, связанных с некорректными настройками, и упростить аудит для служб безопасности. Для нас это был стратегически важный шаг для построения надежной, автоматизированной системы управления доступом.