Как я понимаю, Kafka, идентификатор группы потребителей и THAT ALONE определяют, принадлежат ли N> 1 экземпляры потребителей / входят в ту же группу потребителей.То, что я размышляю о нашем кластере, - это то, что люди могут раскручивать потребителей для чтения тем без необходимости настраивать ACLS.Некоторые темы будут предназначены для общего пользования, а другие могут быть более ограничены ACL.У нас есть полностью керберизованный кластер, BTW.
Например, предположим, что я контролирую только запись доступ к темам через ACL, чтобы гарантировать, что ТОЛЬКО предполагаемый производитель может публиковать данные.Но я хочу разрешить кому-либо использовать данные из этой темы.Конфигурация ACL будет выглядеть примерно так:
Current ACLs for resource `Group:*`:
User:* has Allow permission for operations: Read from hosts: *
Current ACLs for resource `Topic:minute-stats`:
User:* has Allow permission for operations: Describe from hosts: *
User:* has Allow permission for operations: Read from hosts: *
User:bob has Allow permission for operations: Write from hosts: *
В этом примере пользователь bob является владельцем приложения, публикующего данные, и мы ТОЛЬКО хотим разрешить этому пользователю публиковать.Однако мы хотим разрешить любому пользователю "*" использовать из этой темы и использовать любой идентификатор группы "*", который он хочет.Цель состоит в том, чтобы сделать доступ к потоку данных по этой теме самообслуживанием.Вы раскручиваете потребителя, выбираете идентификатор группы, и у вас есть доступ.
Проблема с этим подходом состоит в том, что, если два пользователя раскручивают потребителей и случайно выбирают имена идентификаторов групп, которые сталкиваются, то второеstart присоединится к первой группе потребителей и начнет откачивать данные от первого потребителя (при условии, что здесь> 1 раздел, который, как мы предполагаем, имеет место).Это действительно плохо.
Итак, кто-нибудь знает способ включения такой среды самообслуживания для использования тем, которые определены как «общедоступные» (ACL с пользователем: *), и НЕ запускаетриск столкновения имен идентификаторов групп, что может привести к непреднамеренному перехвату данных.Я не вижу никакого способа сделать это.
Возможное решение
Я думаю, что один из способов это могло бы сработать, если бы брокеры Kafka использовали какое-то пространство имен в группеИдентификаторы, которые могут быть включены, возможно, вариант конфигурации.Например, если для создания «эффективного» идентификатора группы использовался идентификатор пользователя, которому принадлежал процесс потребителя, то такой сценарий мог бы быть возможным:
Пользователь »Боб"владеет новым потребительским процессом, запускающимся
Пользователь" bob "был сообщен брокерам как часть аутентификации Kerberos между новым начинающим потребителем и брокерами
Для процесса потребителя "bob" настроено имя идентификатора группы "myconsumer"
Брокер использует идентификатор пользователя + идентификатор группы для формирования "эффективной" группыИдентификатор «bob-myconsumer»
Если в этом примере у пользователя «jane» уже была запущена группа потребителей, и она просто выбрала «myconsumer» для идентификатора своей группы, тоее "эффективный" идентификатор группы был бы вынужден "jane-myconsumer".Потребитель Боба НЕ будет непреднамеренно присоединяться к ее группе потребителей и откачивать разделы данных, потому что их «эффективные» идентификаторы группы не совпадают.