Комментарии 17
Спасибо - отличная статья, даже не столько про именно авторизацию, сколько про архитектуру большой кафки. Вопрос: получилось, что повезло, что авторизация в чистом поле строилась, и до этого не было ничего, а как аналогичный процесс провернуть для тех, кто вырос, и пытается съехать с легаси ACL на RBAC?
В целом, можно представить себе автоматизацию такого переезда: синхронизировать текущее состояние ACL с ролями во внешней IAM системе. И дальше аналогично описанному переключать клиентов.
Но, на самом деле, в нашей конфигурации и объемах ACL могли бы вообще не завестись, как основное решение, т.к. это создало бы большую нагрузку на ZK, который очень ограниченно масштабируется.
Здравствуйте
как связаться с реальными людьми техподдержки озона? Если конечно она вообще существует - по всем контактам, которые находил, отвечают боты
Статья уровня Хабра, конечно. Facepalm.jpg
Увидел статью "Авторизация в Kafka", думаю о! сейчас прочитаю про "подписание сообщений", но нет.
Первый звоночек был, когда прочитал "просто включить флажок в конфиге" - в принципе уже тогда было понятно, что до подписании сообщений так и не добрались.
Второй звоночек был, когда прочитал "Мы используем Kafka с ZooKeeper" - действительно, зачем современные подходы с KRaft?
Ситуация стала немного понятнее, когда прочитал "Проблема в другом: это больно в поддержке. Любая ошибка — это долгое расследование. Любая интеграция — головная боль с поиском всех, кого можно задеть. А гарантий — никаких.".
Теперь понятно, решалась проблема с контролем топиков. Но это немного не то. Обычно под авторизацией в кафке понимают совсем другие вещи, в первую очередь нацеленные на безопасность финансовых пользователей. По факту вы улучшили свою безопасность всего на 5%. Те действия по аутентификации и авторизации, которые были предприняты, все равно оставляют у клиента монопольный доступ к топику. Т.е. если в топике хранятся финансовые данные пользователей, то клиент, теоретически, может создать сообщение под любого пользователя, изменив его финансовые данные. Это и есть стандартная проблема кафки, как транспорта. И обычно (в финтехе) эта проблема решается за счет подписывания сообщений с помощью пользовательских сертификатов, т.е. перед тем, как положить сообщение в топик, его надо подписать. А после того, как консьюмер достает сообщение, он должен снять подпись (убедиться, что подписано пользовательским сертификатом).
Нет, понятно, что если речь идет о каких-то простых, не финансовых сервисах, типа соц.сетей, то там такая безопасность не требуется. Но у Озона вроде как есть даже Банк? Ну понятен теперь уровень этого "Банка".
К слову сказать, у нас много кто не соблюдает безопасность, я это называю "бизнес по-русски". В западных проектах обычно более серьезное отношение к безопасности. У наших видел подписание сообщений в кафке только у Московской биржи. У ВТБ же, напротив, ничего не подписывают, типа из соображений производительности.
Ну ладно, вернемся к статье. Третий звоночек был, когда прочитал "TLS-клиентская аутентификация даёт overhead на потребление CPU" - ну это примерно то же самое, что сказать "https даёт overhead на потребление CPU". Но при этом, почему-то, никто не отказывается от https в пользу http (разве что внутри замкнутых контуров). Короче, другими словами Озон "не смог в TLS". Хотя, в конце статьи, все таки признается, что смог: "Вручную выдали несколько таких сертификатов с небольшими сроками жизни".
Открою секрет, для генерации JWT-токена используются TLS-сертификаты. Т.е. TLS-сертификаты у вас все равно есть, и именно их вы используете для аутентификации, причем, видимо, долгоживущие TLS-сертификаты, что, опять таки, не безопасно.
Если бы вы делали все по правильному, то надо было настроить автоматическую ротацию TLS-сертификатов, и сделать у них маленький срок жизни. Но если бы вы это сделали (т.е. автоматизированный выпуск TLS-сертификатов), то тогда спокойно смогли бы использовать основной механизм аутентификации в кафке через TLS-клиентскую аутентификацию. И не нужно было бы городить огород с "SASL/OAUTHBEARER" и решать все эти возникшие проблемы. Но настоящий разработчик идет своим путем: создает себе проблемы (в виде использования не основного механизма аутентификации), а потом их героически преодолевает.
Ну что ж, четвертый звоночек был, когда прочитал "Представьте, у какого-то сервиса работает, допустим, 50 подов (реплик в K8s). Каждый из них читает свою партицию в Kafka. И тут по какой-то причине остаётся только 49 подов на 50 партиций топика.". Наверное, уже после этого можно давать занавес. Кстати, это стандартный вопрос на собеседовании "соотношение консьюмеров и партиций в кафка", и стандартный ответ, что одних должно быть в 10 раз больше, чем других, из соображений перебалансировки.
И, напоследок: "И вот представьте, спустя долгие месяцы подготовки, команда инженеров собралась на звонок. Как в голливудском фильме — кто-то дал обратный отсчёт.".
Вот, честно, прочитайте про "Staging-production Deployment", и при выкладке на продакшен ни у кого никаких капель пота с лица стекать не будет.
Короче, совет Озону, возьмите в штат нормального архитектора (с ЗП от 500К), и большей части проблем избежите. А если у вас уже есть такие (с ЗП от 500К), то увольняйте их нафиг, и возьмите новых.
Так если уже используют SASL, зачем еще раз повторно подписывать?
Если права нормально разданы на конкретных пользователях, с конкретными доступами(продюсинг онли\консюминг онли)
Спасибо за подробный разбор. Отвечу по пунктам.
Мы используем Kafka с ZooKeeper" - действительно, зачем современные подходы с KRaft
KRAFT — не решает те проблемы о которых я писал в статье. Но решаеттт другие. Поэтому да, мы в процессе миграции. Об этом, возможно, будет другая статья.
Те действия по аутентификации и авторизации, которые были предприняты, все равно оставляют у клиента монопольный доступ к топику
Все верно, доступы каждого клиента мы делим только на RO/RW для всего топика целиком. При этом, стоит пояснить, что «клиент» — это сервис в кубере. Никто больше не может представится этим клиентом. На продакшен окружении в эти поды нет доступа у разработчиков. То есть разработчик доступ к данным получить не может (этим механизмом). Код же клиента мы считаем доверенным, т.к. он прошел все нужные процедуры до попадания в продакшен.
Но у Озона вроде как есть даже Банк? Ну понятен теперь уровень этого "Банка".
У банка отдельный контур и отдельная кафка. Но я все еще не совсем понимаю какую дополнительную безопасность обеспечивает подпись каждого сообщения в общем случае.
"TLS-клиентская аутентификация даёт overhead на потребление CPU" - ну это примерно то же самое, что сказать "https даёт overhead на потребление CPU". Короче, другими словами Озон "не смог в TLS".
Причем тут «смог» или «не смог». В этом блоке я просто перечислял плюсы и минусы разных подходов. Выбранный подход имеет ряд преимуществ.
Если бы вы делали все по правильному, то надо было настроить автоматическую ротацию TLS-сертификатов, и сделать у них маленький срок жизни.
Действительно, так можно было сделать. Буду рад, если приведете какие-то дополнительные аргументы «правильности» такого подхода. Нам он показался существенно более сложным и дающим дополнительные риски.
это стандартный вопрос на собеседовании "соотношение консьюмеров и партиций в кафка", и стандартный ответ, что одних должно быть в 10 раз больше, чем других, из соображений перебалансировки.
Очень спорное утверждение. Количество подов сервиса — это сложны баланс между стабильностью, балансировкой и потреблением ресурсов. Да, периодически делают количество консьюмеров больше, чем число партиций для того, чтобы не возникло проблем при временной недоступности части подов. Но это имеет смысл тогда, когда основаная нагрузка сервиса — обработка асинхронных сигналов.
Зачем нужен запас x10 мне точно не понятно. Наоборот, ребаланс группы будет происходить значительно дольше, т.к. при стандартном ассайменте каждый вход/выход клиента из консьюмер-группы будет приводить к полному ребалансу группы и простою чтения.
Вот, честно, прочитайте про "Staging-production Deployment", и при выкладке на продакшен ни у кого никаких капель пота с лица стекать не будет.
Рад, что вас так захватило повествование, что вы не заметили моего художественного вымысла в этом месте. Но поясню — эта сцена была мной добавлена для того, чтобы статья чуть легче читалась к концу.
Короче, совет Озону, возьмите в штат нормального архитектора (с ЗП от 500К), и большей части проблем избежите.
Спасибо за совет. Но более конструктивно было бы обсудить то, а какие, собственно, проблемы мы не решили. Предлагаю продолжить диалог о них.
Приключенческий фентези техно боевик прочел. Столько приготовлений и финал как в фильмах. Конечно интересно. 😃🤌
Планируется ли выкладывать этот прокси-демон kafka offline permissions в открытый доступ или как дополнение прямо в strimzi репозиторий.
Кажется, что это может быть полезно для сообщества.
Очень занятный и длительный квест... Спасибо за детальное описание!
В статье не нашел объяснения, чем не устроил например SASL/SCRAM. Аутентификация в этом случае проходила бы через брокеров в зукипере. Управлять учетками можно терраформом например. Кажется все приложения, работающие с кафкой должны держать постоянные коннекты и отсюда следует, что нагрузки большой это давать на зукипер не должно (исключение - какие-то массовые сбои, но даже в этом случае рассосется нагрузка и все подключатся в итоге)... или есть какие-то нюансы, нераскрытые в статье?
По авторизации путь с OAuth завел вас совсем в глубокий лес с необходимостью реализации еще дополнительной обвязки с кешированием инфы локально. Т.е. такой серьезный объем дополнительной поддержки. А стандартными средствами кафки эта инфа также хранится в зукипере и тоже кажется не должно вызывать проблемы...
Преобразование ролей в ACL для конечных юзеров в целом можно было за пределами кафки (в коде по менеджменту учеток и ACL) с любой удобной гибкостью дешевыми средствами на любом языке.
Возможно были какие-то причины продолжать копать в сторону OAuth несмотря на появляющиеся проблемы?
У нас довольно много партиций в кластере (более 100 000) и во время отключения/включения датацентра нагрузка на него очень существенная. Мы хотели как можно меньше нагружать ZK дополнительно. В моменте — это была главная причина.
Если говорить о стратегии, то мы отказываемся от kafka на ZK в пользу kraft. Кроме того, уходим от концепции единого кластера, к концепции нескольких инстоляций под единым прокси-сервисом. Так, чтобы для пользователей это все еще была единая большая кафка. Не могу сказать, что в этом случае, ваш вариант нельзя использовать. Но там сложность так же вырастает.
Ну и третья причина, которую я не стал описывать в статье — в Озоне есть единый подход к внутренней аутентификации сервисов друг в друга и в инфраструктуру и мы хотели, чтобы с кафкой он был таким же.
Но спасибо вам большое за комментарий — кому-то из читателей он может оказаться очень полезным.
Я вот только одного не понял: получается до какого-то года (2025?) в Озоновской кафке не было ни авторизации ни аутентификации? Типа приходи кто хочешь, бери что попало?
Авторизацию включили чуть раньше, но действительно было время, когда общего решения действительно не было. И приходилось контролировать, что туда не попадут персональные данные и другая чувствительная информация.
Вместо того, чтобы отправлять эти данные приходилось, например, отправлять только идентификатор события, а сами данные отдавать синхронно по gRPC. Редко применялись такие методики, как шифрование данных или подпись каждого сообщения.
Ну и некоторые данные доставлялись в отдельных кластерах Kafka. Так есть и сейчас, например, общая кафка, конечно, никак не касается банковского контура.
Отличная статья, особенно интересно было читать о возможных альтернативах и объяснения, почему они не подходят в конкретной ситуации
Авторизация в Kafka: управление изменениями, когда у тебя тысячи клиентов и миллионы RPS