Увидел статью "Авторизация в 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К), то увольняйте их нафиг, и возьмите новых.
по поводу майнинга скажу так, что есть ряд сайтов, которые в своем джаваскриптовом коде содержат что-то подобное. и я, вы не поверите, все равно захожу на эти сайты и пользуюсь их функционалом, даже несмотря на то, что они в этот момент пользуются моими ресурсами. так устроен мир: что-то берешь, а что-то отдаешь. при этом, конечно, нигде на сайте не написано, что они делают. но лично я готов закрыть на это глаза. есть платные аналоги, где ничего не майнят, но цена намного выше стоимости ресурсов моего компа.
ходите через оперу-мини (или подобные, которые рендерят страницу на сервере) и будет вам счастье. вообще, смешно, конечно, выглядят попытки «заблочить вредный скрипт» и т.п. свои локальные уязвимости не хотите лучше заблочить? я, например, не собираюсь ничего блочить, даже после того, как узнал, что какой-то скрипт может пробить мои порты. ну пробил он их и что? не жарко и не холодно от этого. содержите свою систему в порядке и не нужно будет беспокоиться по поводу скриптов.
Статья уровня Хабра, конечно. 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К), то увольняйте их нафиг, и возьмите новых.
по поводу майнинга скажу так, что есть ряд сайтов, которые в своем джаваскриптовом коде содержат что-то подобное. и я, вы не поверите, все равно захожу на эти сайты и пользуюсь их функционалом, даже несмотря на то, что они в этот момент пользуются моими ресурсами. так устроен мир: что-то берешь, а что-то отдаешь. при этом, конечно, нигде на сайте не написано, что они делают. но лично я готов закрыть на это глаза. есть платные аналоги, где ничего не майнят, но цена намного выше стоимости ресурсов моего компа.
ssh закрывается паролем или сертификатом, http на post запросы закрывается паролем. torrent то чем не угодил?
комментарии излишни