Ребята, я тут уже обгуглился) может кто решал подобную задачу

(кажется типичной) и сможет подсказать.
Дано - aws msk, уже вовсю пару лет в продакшене, нет ни авторизации, ни аутентификации. То есть все, у кого есть сетевой доступ, могут создавать, удалять, писать, читать топики. Топики создаются либо клиентами, либо через autocreation (ну ещё руками через kpow).
Собсно, задача засекьюрить это все дело, сделать acl и начать централизованно управлять топиками.
Вопрос больше по централизованному управлению, ищу что-то в IaC парадигме. Свой велосипед писать крайне не хочется, из готового нашёл terraform provider https://registry.terraform.io/providers/Mongey/kafka/latest/docs либо поставить strimzi оператора(user и topic) в stand alone режиме, подрубить его к кафке и уже рулить топиками как k8s ресурсами. Оба варианта имеют как плюсы, так и минусы и не выглядят сильно production ready решениями (провайдер не официальный, создаёт очень много ресурсов (на каждый топик и verb по отдельному acl, а стримзи задействует много доп компонентов, в первую очередь нам кубер нужен. Ну и опять же community проект). Почему указал вначале про авторизацию, потому что юзеров тоже как-то надо менеджерить и хотелось бы одной тулой закрыть оба вопроса. В общем, не упускаю ли какого-то прекрасного солюшена, который закроет потребности?

переезжал (и продолжаю переезжать) на sasl_ssl в этом году. юзаю scram, пока менеджерю юзеров и ацл терраформом (только провайдер другой - https://registry.terraform.io/providers/zywillc/kafka/latest (по сути то же самое). В ближайшей перспективе прикручу вольт для хранения секретов, есть рандек - там кнопки для команд, чтобы сами создавали себе все. В качестве замены terraform можно поискать в ansible (кажется там было чот). strimzi не смотрел, кафка не в кубе, не могу оценить, насколько им удобно будет менеджерить

А кто будет айдентити источником?

Так кафка, скрам же. Или не об этом вопрос?

Я думал для да SASL_SSL будет какой-то внешний источник пользователей, видимо как-то неправильно понял, сорри

Рандек - это вот эта штука? https://www.rundeck.com/blog/self-service-operations-solves-security-and-compliance-problems Получается, 2 источника правды для кафки? Один - тераформ в коде, второй - что натычут юзеры в админке? (или что-то подобное, не знаком с этой штукой)

Рандек( да, это оно) - это просто кнопки, в моем случае он просто запускает терраформ , который накатывает конфиг на Кафку. Сейчас конфиг создаются руками. В идеальном мире так: пользователь ( админ, разраб, итд) говорит рандеку - хочу такого юзера в таком то кластере Кафки. Рандек запускает автоматику - генерит конфиг для терраформ, генерит пароль, складывает его в вольт , отправляет пользователю, накатывает конфиг на кафку. Потом пользователь говорит, для этого юзера нужны такие от права и тычет кнопку. Флоу примерный, до конца еще не разработан

Звучит, как вполне себе план. Примерно такую схему себе и представляю. Это все на MSK или оригинальная Кафка?

В разных облаках в мск. Ванильная кафка внутри вм

А что думаете про нативный sasl/scram от aws msk? Храним юзеров в secret manager, ассоциируем этот secret с msk кластером. А дальше уже внутренними acl накручиваем права. Меня смущает ограничение в 1000 юзеров на кластер, ну и ещё некоторые лимиты

Не могу оценить, не юзал apache Kafka msk, но если все целиком там, то почему бы нет. Может кто нибудь еще из чата поделится реливантным опытом с msk.

Юзаем уже год. Полет отличный. Один за..б - оно хранит все версии секретов. Т.е. поменяли секрет в сикретсманагере - и теперь можно логиниться двумя паролями 🤷‍♂ Есть решение, и саппорт это признает, но первый раз такая ситуация выглядит кринжово))

Ну так-то это удобно на самом деле, позволяет гарантировано бесшовно пароли менять. Главное, не забыть старый вычистить. Но конечно scram и без этого бесшовно работает, если случайно с рестартом не совпадёт...

О, мы на редисе такое же поведение с паролями поймали(можно подключиться и с новым и со старым). А может подскажете, где это поведение описано или может issue открыто? Чет сходу не нагуглилось.

Та прям в доке) Ща чекну

Revoking user access: To revoke a user's credentials to access a cluster, we recommend that you first remove or enforce an ACL on the cluster, and then disassociate the secret. This is because of the following: Removing a user does not close existing connections. Changes to your secret take up to 10 minutes to propagate. Очень размыто. И пояснения отстойные про 10 минут. Я ждал 2е суток - старый пароль работал норм. Написал в саппорт - сказали так и должно быть. Сказали что - только лишь передергивание секрета сбрасывает кеши версий сикрета в брокере. И только после этого останется последняя версия сикрета

А что значит передергивание секрета?

Точно, помню эту фразу. Ну тут 10 минут - это скорее про то, что новый заработает в течение 10 минут

То что и написано в инструкции - диссоциация и ассоциация

Ох блин) какой-то лютый костыль

Найдете как обойти, поделитесь плиз)

Да, сто процентов будем искать что-то. Но с другой стороны, если этот метод саппорт предлагает - не факт, что существует альтернатива. Щас появилось подозрение, что половина всех секретов - dummy (тераформом клали value = dummy, потом руками меняли в aws console)