Комментарии 10
Спасибо, было интересно. Не знал что есть такое opa и статья демонстрирует хорошую инженерную культуру. В результате получилось удобное решение для работы с Kafka acl
Теперь к недостаткам, почему всего 1 альтернативный вариант?
Решение получилось, на мой взгляд, спорное, opa тут выглядит как усложнение, почему не написать свой авторайзер? Как вариант, если уж задумались об acl,которые не поддерживают rbac или группировку, то почему не использовать код генерацию для acl? Исходят из тех же топиков, уже можно сгенерить большую часть acl. И синхронизировать их тем же стримзи оператором
Если же вы не знаете какие есть топики и принципалы, то почему задумались об acl в принципе? А если речь идёт об ограничении доступа к одному топику, то можно настроить acl только там и оставить остальные без ограничений
В первую очередь хотел бы поблагодарить за комментарий!
С недостатком по количеству рассмотренных (а точнее описанных решений) не могу не согласиться. Было решено проводить подробное тестирование именно этих двух как самых потенциально интересных для нашего случая.
По поводу своего авторайзера могу сказать, что нам показалось уместным использовать уже существующее решение, к тому же, можно сказать, что OPA становится этаким корпоративным стандартом. Всегда удобнее применять одно решение в нескольких местах, банально потому, что с ним уже знакомы инженеры.
Код генерации ACL мог быть написан, Вы правы, однако актуальным встает вопрос о его декларативности и идемпотентности. Например, в таком варианте требуется очень аккуратно обрабатывать случаи, когда ACL не создался или когда его нужно удалить, в данной ситуации OPA решает проблемы за счет своего архитектурного дизайна.
Спасибо за наводку на Strimzi, изучим подробнее. Но насколько я вижу, это решение именно для k8s и использовать его для управления политиками на внешних кластерах — не целевая история (пока не вижу такого примера даже), а одно из наших требований состояло в реализации всего вышеперечисленного с bare‑metal кластером Kafka.
Спасибо за ответ и разъяснения! Если OPA уже используется или планируется применять где-то ещё, то все становится более прозрачно. А почему выбрали "сайдкар" c opa(если я правильно понял этот момент) ? Исключительно для экономии трафика или есть заметный профит по латенси? Или дело в том, что он не поддерживает кластеризацию и таким образом вы увеличиваете доступность приложения?
Также расскажите пожалуйста про Kraft, во первых что имеется в виду? Брокер с ролью контролёр(тогда почему именно он) или любой брокер просто речь про кафку на рафте, а не зукипере? (Тогда упоминание Kraft не кажется существенным, кажется что зк и рафт в данном сценарии не имеет различий)
Strimzi интересный проект, стоит внимания, но довольно монструозный и имеет определенный порог вхождения. Я имел в виду что можно пересобрать strimzi под себя и заставить обрабатывать acl с любым кластером, даже bare metal, однако, если в этом контуре нет k8s, то затея сомнительная.
Если под «сайдкаром» Вы имеете в виду расположение OPA‑сервера на одной ноде с Kafka (и так для каждой ноды), то такое расположение было выбрано из‑за рекомендация на сайте OPA — рекомендуется располагать OPA как можно «ближе» к использующему его компоненту (в том числе, как Вы и отметили, для снижения сетевой нагрузки и задержек). Что касается задержек, то могу сказать, что ощутимых задержек со «внешней» OPA мы не обнаружили, однако решили прислушаться к рекомендациям на оф. сайте.
Сама по себе OPA не имеет кластреного режима, поэтому каждому узлу кластера Kafka было решено подселить по «собственной» OPA Server.
Да, речь именно про Kafka на KRaft (а не Zookeeper), упоминание сделано для описания конфигурации тестового стенда, акцентировано внимание на этом потому, что в примере на оф. сайте OPA указана конфигурация с Zookeeper, несмотря на то, что теоретически влияния этот факт не должен оказывать, была необходимость проверки его на практике. В том числе именно поэтому было интересно пронаблюдать поведение компонента KRaft и Kafka по отдельности.
Понятно, спасибо ещё раз за пояснения!
Понимаю почему вы уделили этому внимание. Логически, должно работать с рафтом, так как в контексте acl метаданные хранятся или в zookeeper или raft (или дублируются, если кластер в процессе миграции на raft). В случае с opa, метаданных нет, вся логика на стороне opa.
пересобрать strimzi под себя и заставить обрабатывать acl с любым кластером
Звучит, если честно, как еще бОльшее усложнение по сравнению с пайплайном и явно конфигурируемой OPA. Не говоря уже о том что подобные пересборки усложняют как архитектуру на этапе создания, так и последующую эксплуатацию.
Не могу не согласиться что решение спорное, но у меня не сложилось впечатления, что Opa будет легче в поддержке, видя последним релиз 2 года назад и 61 звезду на гитхабе(в Кафка репозитории)
Отмечу, что это не сама OPA (как раз она развивается намного активнее), а именно Kafka OPA Plugin, как раз в статье пытались исправить эту ситуацию, став контрибьюторами проекта.
Спасибо за материал, видно основательность подхода. А почему решили использовать именно Kerberos?
Благодарю за высокую оценку материала!
Поскольку мы искали пути решения по удобному управлению политиками в уже существующих у нас кластерах Kafka, то данный метод аутентификации был одним из "вводных условий" задачи.
Но описанное решение также без проблем может быть применено и с другими механизмами аутентификации Kafka.
Policy as Code в Apache Kafka: опыт внедрения Open Policy Agent