Невозможно настроить межаккаунтную связь между AWS Lambda и AWS Kafka (кластер MSK)

Question

У меня есть конечная цель - запустить AWS Lambda из тем Kafka, где Kafka - это кластер MSK, работающий в другой учетной записи AWS.

Настраивать.Кластеры Lambda и MSK находятся в разных аккаунтах AWS. Каждый из них подключен к своему собственному VPC, то есть подсети (частной через NAT GW), и защищен брандмауэром группой безопасности (я сделал их все - позволяющими ради эксперимента)

Непосредственная проблема.Я не могу использовать «триггер MSK» для лямбда-выражения, потому что он требует указания ARN для кластера MSK, но это невозможно, поскольку этот кластер MSK находится в другой учетной записи и на него нельзя ссылаться в контексте лямбда-триггера.

Проблема, которую я пытаюсь решить.Я пытаюсь использовать «триггер Kafka», для которого требуется спецификация сервера начальной загрузки (он у меня есть), название темы (у меня есть), размер пакета и начальная позиция (не проблема). Проблема во второй группе опций, которая позволяет аутентифицировать лямбда-триггер перед кластером MSK. Это может быть 1) настройка на основе сети в форме комбинации VPC/Subnet/SecurityGroup кластера MSK, 2) настройка на основе секретов в форме конфигурации SASL/xxx.

Первый вариант, то есть настройка на основе сети, не может быть использован, поскольку для него требуется VPC и другие параметры из кластера Kafka, то есть подсети и группы безопасности, которые недоступны в учетной записи, где настраивается Lambda.

Последнее требует указания одного из методов SASL, то есть PLAIN, SCRAM512 и SCRAM256 в паре со ссылкой на запись SecretManager, в которой хранится комбинация имени пользователя и пароля. Я выбрал этот метод как единственный (на мой взгляд) теоретически возможный для межаккаунтного общения.

Что я сделал:

1. В учетной записи Lambda я создал запись в SecretManager с двумя ключами: username а также password и некоторые конкретные значения
2. В учетной записи Kafka я включил аутентификацию SASL / SCRAM для кластера MSK. Это потребовало настройки записи в SecretManager, что я и сделал. Я использовал те же учетные данные, что и в секрете на Лямбда-аккаунте. После этого я вижу 3 варианта загрузочного сервера: <hostname>:9092 (простой текст), <hostname>:9094 (TLS) и <hostname>:9096 (SASL/SCRAM).
3. Я использовал спецификации сервера начальной загрузки (с портом 9096) в настройке триггера kafka для моей лямбда-функции.
4. Чтобы предоставить возможность подключения между учетными записями между подсетями Lambda и Kafka, я настраиваю коннектор VPC Peering с соответствующими правилами в таблицах маршрутизации.
5. Я проверил связь между этими подсетями, запустив EC2 в подсети Lambda, и попытался nmap -Pn -p 9092,9094,9096 <bootstrap server hostname> чтобы получить следующий ответ:

      PORT     STATE SERVICE
9092/tcp open  unknown
9094/tcp open  unknown
9096/tcp open  unknown

Nmap done: 1 IP address (1 host up) scanned in 0.03 seconds

Итоги.Независимо от того, что я пробую с точки зрения другой комбинации сервера / порта начальной загрузки и метода SASL, я получаю эту ошибку на стороне триггера Lambda: ПРОБЛЕМА: ошибка подключения. Проверьте конфигурацию подключения к источнику событий

Я не могу найти способ отладки этого сценария ошибки, поскольку другие подробности не предоставлены. Включение CloudWatch в кластере MSK не помогло, поскольку оно не собирает никакой полезной информации.

Answer 1

Не ответ, а скорее архитектурная идея, которая может привести к ответу.

Я заставил это работать через триггер msk на лямбде, но я в той же лодке. Разная учетная запись для msk kafka и lambda.

Мой план: создать службу опроса (пример: приложение Elastic beanstalk nodejs) в той же учетной записи. В теме обновления вызовите шлюз API, чтобы активировать лямбда-выражение в другой учетной записи для обработки. Это будет ваш триггерный центр.

Возможно, мы могли бы запустить лямбду напрямую в другой учетной записи, но создание API позволит упростить тестирование.

Просто убедитесь, что вы добавили подписанный JWT к вызову и используете лямбда-авторизатор для проверки того, кто делает вызов.

Answer 2

Я полностью забросил эту тему, но на самом деле у меня есть решение. Он не такой всеобъемлющий, как хотелось бы, но он работает в нашей производственной установке.

Хитрость заключалась в том, чтобы обе учетные записи могли взаимодействовать через соответствующую настройку однорангового соединения VPC (для каждой учетной записи), а затем использовать сетевую настройку для аутентификации лямбда-триггера, но вместо использования групп безопасности и подсетей MSK мы хотим использовать эти лямбда. Это заставляет триггер «kafka» на стороне Lambda иметь возможность обращаться к загрузочным серверам через VPC самой Lambda.

Недостатком этого метода является то, что он работает только для обычного текстового соединения. Скорее всего, он будет работать с зашифрованным трафиком, но я не пробовал, поскольку мы полагаемся на изолированный характер этих VPC.