Отмечу, что это не сама OPA (как раз она развивается намного активнее), а именно Kafka OPA Plugin, как раз в статье пытались исправить эту ситуацию, став контрибьюторами проекта.
Если под «сайдкаром» Вы имеете в виду расположение OPA‑сервера на одной ноде с Kafka (и так для каждой ноды), то такое расположение было выбрано из‑за рекомендация на сайте OPA — рекомендуется располагать OPA как можно «ближе» к использующему его компоненту (в том числе, как Вы и отметили, для снижения сетевой нагрузки и задержек). Что касается задержек, то могу сказать, что ощутимых задержек со «внешней» OPA мы не обнаружили, однако решили прислушаться к рекомендациям на оф. сайте.
Сама по себе OPA не имеет кластреного режима, поэтому каждому узлу кластера Kafka было решено подселить по «собственной» OPA Server.
Да, речь именно про Kafka на KRaft (а не Zookeeper), упоминание сделано для описания конфигурации тестового стенда, акцентировано внимание на этом потому, что в примере на оф. сайте OPA указана конфигурация с Zookeeper, несмотря на то, что теоретически влияния этот факт не должен оказывать, была необходимость проверки его на практике. В том числе именно поэтому было интересно пронаблюдать поведение компонента KRaft и Kafka по отдельности.
Поскольку мы искали пути решения по удобному управлению политиками в уже существующих у нас кластерах Kafka, то данный метод аутентификации был одним из "вводных условий" задачи.
Но описанное решение также без проблем может быть применено и с другими механизмами аутентификации Kafka.
В первую очередь хотел бы поблагодарить за комментарий!
С недостатком по количеству рассмотренных (а точнее описанных решений) не могу не согласиться. Было решено проводить подробное тестирование именно этих двух как самых потенциально интересных для нашего случая.
По поводу своего авторайзера могу сказать, что нам показалось уместным использовать уже существующее решение, к тому же, можно сказать, что OPA становится этаким корпоративным стандартом. Всегда удобнее применять одно решение в нескольких местах, банально потому, что с ним уже знакомы инженеры. Код генерации ACL мог быть написан, Вы правы, однако актуальным встает вопрос о его декларативности и идемпотентности. Например, в таком варианте требуется очень аккуратно обрабатывать случаи, когда ACL не создался или когда его нужно удалить, в данной ситуации OPA решает проблемы за счет своего архитектурного дизайна.
Спасибо за наводку на Strimzi, изучим подробнее. Но насколько я вижу, это решение именно для k8s и использовать его для управления политиками на внешних кластерах — не целевая история (пока не вижу такого примера даже), а одно из наших требований состояло в реализации всего вышеперечисленного с bare‑metal кластером Kafka.
Отмечу, что это не сама OPA (как раз она развивается намного активнее), а именно Kafka OPA Plugin, как раз в статье пытались исправить эту ситуацию, став контрибьюторами проекта.
Если под «сайдкаром» Вы имеете в виду расположение OPA‑сервера на одной ноде с Kafka (и так для каждой ноды), то такое расположение было выбрано из‑за рекомендация на сайте OPA — рекомендуется располагать OPA как можно «ближе» к использующему его компоненту (в том числе, как Вы и отметили, для снижения сетевой нагрузки и задержек). Что касается задержек, то могу сказать, что ощутимых задержек со «внешней» OPA мы не обнаружили, однако решили прислушаться к рекомендациям на оф. сайте.
Сама по себе OPA не имеет кластреного режима, поэтому каждому узлу кластера Kafka было решено подселить по «собственной» OPA Server.
Да, речь именно про Kafka на KRaft (а не Zookeeper), упоминание сделано для описания конфигурации тестового стенда, акцентировано внимание на этом потому, что в примере на оф. сайте OPA указана конфигурация с Zookeeper, несмотря на то, что теоретически влияния этот факт не должен оказывать, была необходимость проверки его на практике. В том числе именно поэтому было интересно пронаблюдать поведение компонента KRaft и Kafka по отдельности.
Благодарю за высокую оценку материала!
Поскольку мы искали пути решения по удобному управлению политиками в уже существующих у нас кластерах Kafka, то данный метод аутентификации был одним из "вводных условий" задачи.
Но описанное решение также без проблем может быть применено и с другими механизмами аутентификации Kafka.
В первую очередь хотел бы поблагодарить за комментарий!
С недостатком по количеству рассмотренных (а точнее описанных решений) не могу не согласиться. Было решено проводить подробное тестирование именно этих двух как самых потенциально интересных для нашего случая.
По поводу своего авторайзера могу сказать, что нам показалось уместным использовать уже существующее решение, к тому же, можно сказать, что OPA становится этаким корпоративным стандартом. Всегда удобнее применять одно решение в нескольких местах, банально потому, что с ним уже знакомы инженеры.
Код генерации ACL мог быть написан, Вы правы, однако актуальным встает вопрос о его декларативности и идемпотентности. Например, в таком варианте требуется очень аккуратно обрабатывать случаи, когда ACL не создался или когда его нужно удалить, в данной ситуации OPA решает проблемы за счет своего архитектурного дизайна.
Спасибо за наводку на Strimzi, изучим подробнее. Но насколько я вижу, это решение именно для k8s и использовать его для управления политиками на внешних кластерах — не целевая история (пока не вижу такого примера даже), а одно из наших требований состояло в реализации всего вышеперечисленного с bare‑metal кластером Kafka.