Новое обновление Apache RocketMQ ACL 2.0

[Превью прямого эфира] Смогут ли крупные модели заменить программистов? "

Автор: Ту Чжун

введение

RocketMQ, как популярное промежуточное программное обеспечение для распределенного обмена сообщениями, широко используется в различных крупномасштабных распределенных системах и микросервисах. Он играет важную роль в асинхронной связи, развязке систем, сглаживании пиков и заполнении впадин, а также в уведомлении о сообщениях. С развитием технологий и расширением масштабов бизнеса проблемы, связанные с безопасностью, становятся все более заметными, а контроль доступа к системам обмена сообщениями становится особенно важным. Однако существующая версия RocketMQ ACL 1.0 больше не соответствует требованиям будущего развития. Поэтому мы выпустили обновленную версию RocketMQ ACL 2.0 для дальнейшего повышения безопасности данных RocketMQ. В этой статье будут представлены новые функции, принципы работы, а также соответствующие конфигурации и практики RocketMQ ACL 2.0.

Обновленный фон

Болевые точки ACL 1.0

Процесс аутентификации и авторизации RocketMQ ACL 1.0 показан на рисунке выше. Во время использования возникают следующие болевые точки:

Белый список IP-адресов для обхода контроля доступа . В стандартных методах обеспечения безопасности белый список IP-адресов часто используется для ограничения доступа клиентов к ресурсам только с определенных IP-адресов или диапазонов IP-адресов. Однако в ACL 1.0 белый список IP-адресов ненормально используется как средство обхода проверки подлинности, что отклоняется от целей безопасности стандартной практики. Это отклонение конструкции может вызвать потенциальные риски безопасности, особенно в сценариях общедоступных сетей, где несколько клиентов используют один и тот же IP-адрес, что может привести к тому, что несанкционированные IP-адреса могут обходить обычные проверки контроля доступа к данным кластера.

Отсутствие детального контроля над API-интерфейсами управления : RocketMQ предоставляет более 130 API-интерфейсов управления и контроля, поддерживая конфигурацию кластера, управление метаданными темы и группы, а также такие операции, как запрос сообщений и сброс сайта. Эти операции включают обработку конфиденциальных данных и влияют на стабильность системы. Поэтому становится критически важно точно определить объем доступных API и данных на основе различных ролей или обязанностей пользователей. Однако ACL 1.0 поддерживает только 9 API, включая темы, метаданные группы и конфигурацию брокера. Остальные API могут быть использованы злоумышленниками для атаки на систему и кражи конфиденциальных данных. Кроме того, реализация контроля доступа для такого большого количества API управления требует большой работы по кодированию с существующим дизайном и увеличивает риск упустить что-то при добавлении новых API.

Отсутствие контроля доступа между компонентами кластера . Архитектура RocketMQ охватывает несколько ключевых компонентов, таких как NameServer, главный-подчиненный узел брокера и прокси. В настоящее время механизм проверки разрешений ключей отсутствует для взаимного доступа между этими компонентами. Таким образом, как только вы создадите подчиненный узел брокера или прокси-компонент вне кластера, вы сможете обойти существующий механизм безопасности и получить доступ к конфиденциальным данным в кластере. Это, несомненно, окажет огромное влияние на безопасность данных и стабильность системы. кластера.

Характеристики и принципы

Новые возможности ACL 2.0

RocketMQ ACL 2.0 решает проблемы ACL 1.0, а также содержит шесть основных новых функций:

Точное определение разрешений ресурсов API : ACL 2.0 определяет все ресурсы в системе RocketMQ, включая кластеры, пространства имен, темы и группы потребителей, для достижения независимого контроля доступа для всех типов ресурсов. Кроме того, он включает все API в сферу контроля разрешений, охватывая различные операции, включая отправку и получение сообщений, управление кластером, метаданные и т. д., гарантируя, что строгий контроль разрешений применяется к любой операции со всеми ресурсами.

Несколько режимов сопоставления для авторизованных ресурсов . В кластерной среде с большим количеством ресурсов авторизация каждого ресурса по отдельности приведет к усложнению процессов настройки и усложнению управления. Таким образом, в ACL 2.0 представлены три гибких режима сопоставления: точное совпадение, совпадение префикса и совпадение с подстановочными знаками. Эти режимы позволяют пользователям быстро выполнять унифицированные настройки на основе соглашений об именах и структурных характеристик ресурсов, упрощают операции по управлению разрешениями и повышают эффективность настройки.

Поддержка контроля доступа между компонентами кластера . Поскольку все типы ресурсов и операции API включены в систему контроля доступа, соединения и доступ между компонентами внутри кластера также подлежат контролю разрешений, включая выбор лидера между главным и подчиненным брокером, а также репликацию данных. процесс, а также доступ к данным от прокси к брокеру и т. д. Это позволяет эффективно избежать потенциальных проблем с утечкой данных и рисков для стабильности системы, а также повысить безопасность и надежность всего кластера.

Разделение аутентификации пользователя и проверки полномочий . Разделяя два ключевых модуля аутентификации и авторизации, система может предоставлять гибкие опции, такие как «только аутентификация без аутентификации», для адаптации к потребностям различных сценариев. Кроме того, эти два компонента могут развиваться и развиваться независимо, что приводит к появлению различных методов аутентификации и расширенных методов аутентификации.

Баланс между безопасностью и производительностью . Когда ACL включен, каждый запрос от клиента должен пройти полный процесс аутентификации и авторизации. Это обеспечивает безопасность системы, но также приводит к увеличению производительности. В ACL 2.0 стратегии аутентификации и авторизации без отслеживания состояния, а также стратегии аутентификации и авторизации с отслеживанием состояния предусмотрены для удовлетворения двух различных требований безопасности и производительности: экстремальных требований безопасности и контролируемой безопасности, но с приоритетом производительности.

Гибкий и расширяемый механизм подключаемых модулей . На современном рынке существует множество реализаций методов аутентификации, а методы авторизации также требуют настройки для различных сценариев. Поэтому ACL 2.0 разработал структуру подключаемых модулей для определения и абстрагирования интерфейсов на разных уровнях для поддержки будущего расширения аутентификации и авторизации и позволяет пользователям настраивать и реализовывать соответствующие решения в соответствии с потребностями их собственного бизнеса.

модель контроля доступа

Управление доступом на основе ролей (RBAC) и управление доступом на основе атрибутов (ABAC) являются двумя основными методами в системе управления доступом. RocketMQ ACL 2.0 объединяет эти два метода для создания более гибкой и мощной системы контроля доступа.

RBAC — это модель управления доступом на основе ролей, в которой разрешения распределяются посредством ролей. RocketMQ ACL 2.0 разделяет роли пользователей на суперпользователей (Супер) и обычных пользователей (Обычные). Суперпользователи имеют самый высокий уровень разрешений и могут получать доступ к ресурсам без авторизации, что упрощает зависимость от разрешений во время инициализации кластера, а также вопросов повседневной эксплуатации и обслуживания. Обычным пользователям необходимо предоставить соответствующие разрешения перед доступом к ресурсам, что подходит для доступа к ресурсам по требованию в бизнес-сценариях.

ABAC — это модель управления доступом на основе атрибутов, которая выражает политику управления доступом через многомерные атрибуты, такие как пользователи, ресурсы, среды, операции и т. д. RocketMQ ACL 2.0 предоставляет этот гибкий механизм контроля доступа для обычных пользователей. Помогите администраторам реализовать более совершенный контроль доступа к ресурсам на основе потребностей бизнеса, обязанностей пользователей и других факторов.

В системе безопасности аутентификация и авторизация играют разные роли соответственно. RocetMQ ACL 2.0 разделяет аутентификацию и авторизацию на модули. Это гарантирует, что оба компонента выполняют свои обязанности, и снижает сложность системы. Службы аутентификации предназначены для проверки легитимности личности пользователей, а службы авторизации сосредоточены на управлении разрешениями пользователей и контроле доступа. Такое разделение не только упрощает управление, поддержку и расширение кода, но также предоставляет пользователям гибкость в использовании. В зависимости от потребностей пользователи могут включить службы аутентификации или авторизации отдельно или включить обе службы одновременно. Это позволяет RocketMQ ACL обеспечить быстрое развертывание простых сценариев и адаптироваться к строгим требованиям безопасности в сложных средах.

Аутентификация

Аутентификация — это механизм безопасности, предназначенный для проверки подлинности лица, инициирующего запрос на доступ. Он используется для обеспечения того, чтобы только законные, прошедшие проверку подлинности пользователи или объекты могли получить доступ к защищенным ресурсам или выполнять определенные операции. Проще говоря, аутентификация — это ответ на вопрос «Кто вы?» перед получением доступа к ресурсу или услуге.

Версия RocketMQ ACL 2.0 поддерживает тот же механизм аутентификации, что и ACL 1.0, то есть метод аутентификации на основе AK/SK. Этот метод в основном использует технологию симметричного шифрования для проверки личности клиента, гарантируя, что конфиденциальная информация аутентификации (например, пароли) не будет передаваться в виде открытого текста в сети, тем самым улучшая общую безопасность аутентификации.

модель агента

Чтобы улучшить контроль доступа и управление разрешениями системы RocketMQ, ACL 2.0 внес следующие улучшения и расширения в основную модель:

1. Абстракция единой субъектной модели. Чтобы реализовать контроль доступа и управление разрешениями различных объектов, разработан единый субъектный интерфейс, позволяющий нескольким экземплярам в системе выступать в качестве субъектов для доступа к ресурсам. В качестве одного из субъектов, осуществляющих доступ к ресурсам, пользователь реализует интерфейс субъекта согласно этой модели. Это обеспечивает возможности расширения для адаптации разрешений к новым типам объектов в будущем.

2. Классификация ролей и предоставление разрешений:

Суперпользователь : для упрощения процесса управления суперпользователю автоматически предоставляются все разрешения без необходимости отдельной настройки, что упрощает инициализацию системы, а также ежедневное управление эксплуатацией и обслуживанием.
Обычные пользователи : разрешения обычных пользователей требуют явной авторизации. ACL 2.0 предоставляет соответствующие инструменты управления разрешениями, которые могут предоставлять соответствующие разрешения обычным пользователям на основе политик организации и требований безопасности.

3. Поддержка управления статусом пользователей. Чтобы справиться с возможными рисками безопасности, такими как утечка пароля пользователя, ACL 2.0 предоставляет функции включения и отключения пользователей. При возникновении инцидента безопасности статус пользователя можно отключить, чтобы быстро остановить кровотечение и тем самым предотвратить несанкционированный доступ.

Процесс сертификации

Клиентский процесс:

При создании запроса RPC клиент проверяет, заданы ли имя пользователя и пароль. Если они не настроены, клиент отправляет запрос напрямую;
Если настроено, предустановленный алгоритм шифрования используется для шифрования параметров запроса и создания соответствующей цифровой подписи (Signature).
Добавьте имя пользователя и подпись к запросу и отправьте его на сервер для аутентификации.

Серверный процесс:

После получения запроса сервер сначала проверяет, включена ли аутентификация, если она не включена, то пройдет без проверки, если включена, то перейдет к следующему шагу.
Сервер анализирует и собирает параметры, связанные с аутентификацией запроса, и получает информацию, включая имя пользователя и подпись.
Запросите информацию, связанную с пользователем, в локальной базе данных через имя пользователя. Если пользователь не существует, обработка будет возвращена как None, если пользователь существует, а затем перейдите к следующему шагу.
Получите пароль пользователя, используйте тот же алгоритм шифрования для шифрования запроса на создание подписи и сравните его с подписью, переданной клиентом. Если они совпадают, аутентификация успешна. Если они несовместимы, аутентификация не удалась.

Авторизация

Основная идея

Авторизация — это механизм безопасности, предназначенный для определения того, имеет ли запрашивающая сторона разрешение на работу с определенным ресурсом. Короче говоря, авторизация — это ответ на вопрос «кто какие операции над какими ресурсами и при каких обстоятельствах выполнил» до того, как к ресурсам будет осуществлен доступ.

Основанный на модели «Управление доступом на основе атрибутов (ABAC)», RocketMQ ACL 2.0 охватывает следующую серию основных концепций. При внедрении системы следующие концепции будут использоваться в качестве руководства для завершения разработки и внедрения всего механизма управления правами и авторизации.

модель разрешения

Основная концепция модели управления доступом на основе атрибутов (ABAC), ACL 2.0, тщательно разработала модель разрешений. Ключевые моменты заключаются в следующем:

Политика обратно совместимых разрешений : по умолчанию ACL 2.0 сопоставляет и проверяет только определенные пользователем разрешения. Если совпадение не найдено, считается, что нет разрешения на доступ к ресурсу. Однако, учитывая, что в ACL 1.0 существует настройка разрешений по умолчанию, которая позволяет по умолчанию определять «доступ без разрешений» и «доступ с разрешениями» для несовпадающих ресурсов. Поэтому мы реализовали совместимость с политикой разрешений по умолчанию, чтобы обеспечить плавный переход от ACL 1.0 к ACL 2.0.

Гибкий режим сопоставления ресурсов . Что касается типов ресурсов, ACL 2.0 поддерживает кластер, пространство имен, тему, группу потребителей и другие типы, которые используются для управления доступом к различным типам ресурсов. Что касается имен ресурсов, введены три режима точного соответствия (LITERAL), сопоставления префиксов (PREFIXED) и сопоставления подстановочных знаков (ЛЮБЫЕ), чтобы помочь пользователям быстро устанавливать унифицированные правила доступа на основе спецификаций именования и структуры ресурсов, а также упростить разрешения. . управлять.

Типы операций с точными ресурсами : с точки зрения интерфейсов отправки и потребления сообщений они определяются как операции PUB и SUB соответственно. С точки зрения интерфейсов управления кластером и ресурсами определены пять операций: CREATE, UPDATE, DELETE, LIST и GET. Благодаря такому уточнению типов операций пользователи могут упростить понимание и настройку операций, не беспокоясь об определенных определениях интерфейса на уровне операций с ресурсами.

Твердая проверка среды доступа . Что касается среды запроса доступа, ACL 2.0 добавляет проверку IP-источника запроса клиента. Эта проверка контролируется на уровне каждого ресурса и может точно контролировать каждый ресурс. Источником IP может быть конкретный IP-адрес или сегмент IP, чтобы обеспечить контроль IP-доступа на различных уровнях детализации и добавить надежную линию защиты для безопасности системы.

Процесс авторизации

Клиентский процесс:

Когда клиент создает запрос RPC, он создает входные параметры интерфейса для этого вызова, и интерфейс соответствует определению операции, лежащей в основе разрешений.
Клиент устанавливает информацию о ресурсе для этого посещения во входных параметрах интерфейса, а затем передает такие параметры, как пользователь и ресурс, на сервер.

Серверный процесс:

После получения запроса сервер сначала проверяет, включена ли авторизация, если не включена, то проходит без проверки, если включена, то переходит к следующему шагу.
Сервер анализирует и собирает в запросе параметры, связанные с авторизацией. Эти данные включают информацию о пользователе, доступных ресурсах, выполненных операциях и запрошенной среде.
Запросить информацию о пользователе в локальном хранилище данных по имени пользователя. Если пользователь не существует, будет возвращена ошибка, если пользователь существует, перейдите к следующему шагу.
Определите, является ли текущий пользователь суперпользователем. Если он является суперпользователем, запрос будет передан напрямую без проверки авторизации. Если это обычный пользователь, перейдите к следующему шагу для подробной проверки авторизации.
Получите соответствующий список политик авторизации на основе имени пользователя, сопоставьте ресурсы, операции и среду, запрошенные на этот раз, и отсортируйте их по приоритету.
Решения принимаются на основе политики авторизации с наивысшим приоритетом. Если политика авторизации разрешает операцию, будет возвращена успешная авторизация. Если операция отклонена, будет возвращена ошибка отсутствия разрешения.

Анализ параметров авторизации

В ACL 2.0 анализ параметров, связанных с авторизацией (включая ресурсы, операции и т. д.), оптимизирован в зависимости от типа операции и частоты запросов.

Жестко закодированный анализ

Для таких интерфейсов, как отправка и потребление сообщений, параметры относительно сложны, а частота запросов относительно высока. Учитывая удобство и требования к производительности парсинга, для парсинга используется жесткое кодирование.

Анализ аннотаций

Для большого количества интерфейсов управления и контроля нагрузка по жесткому кодированию огромна, а частота вызова этих интерфейсов низкая и требования к производительности не высоки. Поэтому для анализа с целью повышения эффективности кодирования используются аннотации.

Приоритет политики разрешений

С точки зрения сопоставления политики разрешений, поскольку он поддерживает режим нечеткого сопоставления ресурсов, один и тот же ресурс может соответствовать нескольким политикам разрешений. Следовательно, необходим механизм приоритетов, чтобы определить, какой набор политик разрешений в конечном итоге будет использоваться.

Предположим, что настроена следующая политика авторизации, и ситуация сопоставления вышеуказанных приоритетных ресурсов выглядит следующим образом:

Стратегия аутентификации и авторизации

Из-за компромиссов и соображений безопасности и производительности RocketMQ ACL 2.0 предоставляет две стратегии аутентификации и авторизации: стратегию аутентификации и авторизации без сохранения состояния (Stateless) и стратегию аутентификации и авторизации с отслеживанием состояния (Stateful).

Стратегия аутентификации и авторизации без сохранения состояния (без сохранения состояния) . В соответствии с этой стратегией каждый запрос будет проходить независимый процесс аутентификации и авторизации и не зависит от какого-либо предыдущего сеанса и информации о состоянии. Эта строгая политика обеспечивает более высокий уровень безопасности. Изменения разрешений могут быть отражены в последующих запросах в режиме реального времени без какого-либо ожидания. Однако эта стратегия может привести к значительному снижению производительности в сценариях с высокой пропускной способностью, например к увеличению использования ЦП системы и увеличению времени выполнения запросов.

Стратегия аутентификации и авторизации с отслеживанием состояния (Stateful) . В соответствии с этой стратегией при одном и том же клиентском соединении, том же ресурсе и той же операции первый запрос будет полностью аутентифицирован и авторизован, а последующие запросы не будут повторно аутентифицироваться и авторизоваться. Этот метод позволяет эффективно снизить производительность и сократить время запроса и особенно подходит для сценариев с высокой пропускной способностью. Однако эта стратегия может привести к нарушению безопасности, а изменения разрешений могут не вступить в силу в реальном времени.

При выборе между этими двумя стратегиями необходимо взвесить требования безопасности и требования к производительности системы. Если система имеет высокие требования к безопасности и может допустить определенную потерю производительности, то стратегия аутентификации и авторизации без сохранения состояния может быть лучшим выбором. Напротив, если системе необходимо обрабатывать большое количество одновременных запросов и требования безопасности могут быть в определенной степени смягчены, тогда стратегия аутентификации и авторизации с отслеживанием состояния может оказаться более подходящей. Во время фактического развертывания решения также следует принимать на основе конкретных бизнес-сценариев и требований безопасности.

Вставной механизм

Чтобы адаптироваться к постоянному развитию методов аутентификации в будущем и удовлетворять индивидуальные потребности пользователей в конкретных сценариях, RocketMQ ACL 2.0 обеспечивает гибкость и масштабируемость во многих аспектах.

Расширение политик аутентификации и авторизации : по умолчанию RocketMQ ACL 2.0 предоставляет политики аутентификации и авторизации без отслеживания состояния (Stateless) и политики аутентификации и авторизации с отслеживанием состояния (Stateful) для удовлетворения требований безопасности и производительности большинства пользователей. Однако в будущем еще можно будет изучить более эффективные стратегии, позволяющие найти баланс между безопасностью и производительностью.

Расширение методов аутентификации и авторизации . В настоящее время на рынке существует множество зрелых реализаций RocketMQ. Он зарезервирован за счет возможностей подключаемых модулей, и в будущем могут быть легко внедрены другие. Механизм аутентификации. Что касается авторизации, RocketMQ реализует набор основных методов авторизации на основе модели ABAC для адаптации к широкому спектру потребностей пользователей. Но он также предоставляет возможности подключаемых модулей, облегчающих адаптацию большего количества решений, соответствующих будущему развитию.

Управление процессами аутентификации и авторизации . На основе шаблона проектирования цепочки ответственности RocketMQ ACL 2.0 гибко организует процессы аутентификации и авторизации по умолчанию. Пользователи могут расширять или переписывать эти узлы цепочки ответственности, чтобы настроить логику аутентификации и авторизации для своих конкретных бизнес-сценариев.

Расширение хранилища пользователей и разрешений : RocketMQ по умолчанию использует RocksDB для хранения данных пользователей и разрешений локально на узле Broker. Однако, реализуя предопределенные интерфейсы, пользователи могут легко переносить эти данные в любую стороннюю службу или систему хранения, тем самым оптимизируя свою архитектуру и эффективность работы.

Журнал аудита

Журналы аудита используются для записи и мониторинга всех операций контроля доступа, связанных с аутентификацией и авторизацией. С помощью журнала обновлений мы можем отслеживать каждый запрос на доступ, чтобы обеспечить надежность и безопасность системы. В то же время это также помогает устранять проблемы, выполнять безопасные обновления и соответствовать требованиям соответствия.

RocketMQ ACL 2.0 поддерживает журналы аудита, связанные с аутентификацией и авторизацией. Формат следующий:

Журнал аутентификации

# 认证成功日志
[AUTHENTICATION] User:rocketmq is authenticated success with Signature = eMX/+tH/7Bc0TObtDYMcK9Ls+gg=.

# 认证失败日志
[AUTHENTICATION] User:rocketmq is authenticated failed with Signature = eMX/+tH/7Bc0TObtDYMcK9Ls+xx=.

Журнал авторизации

# 授权成功日志
[AUTHORIZATION] Subject = User:rocketmq is Allow Action = Pub from sourceIp = 192.168.0.2 on resource = Topic:TP-TEST for request = 10.

# 授权失败日志
[AUTHORIZATION] Subject = User:rocketmq is Deny Action = Sub from sourceIp = 192.168.0.2 on resource = Topic:GID-TEST for request = 10.

Конфигурация и использование

Архитектура развертывания

Что касается архитектуры развертывания, RocketMQ предоставляет две формы развертывания, а именно интегрированную архитектуру хранения и вычислений и архитектуру, разделенную хранилищем и вычислениями.

Интегрированная архитектура хранения и вычислений

В интегрированной архитектуре хранения и вычислений RocketMQ компонент Broker берет на себя обязанности как по вычислениям, так и по хранению, предоставляет внешние сервисы и получает запросы доступа от всех клиентов. Поэтому компонент «Брокер» играет важную роль в аутентификации и авторизации. Кроме того, компонент «Брокер» также отвечает за обслуживание и хранение метаданных, связанных с аутентификацией и авторизацией.

Архитектура разделения хранения и вычислений

В архитектуре разделения хранения и вычислений RocketMQ хранилище обрабатывается компонентом Broker, а вычисления обрабатываются компонентом Proxy. Все внешние запросы обслуживаются прокси. Таким образом, аутентификация и авторизация запросов осуществляется компонентом Proxy. Брокер отвечает за хранение метаданных и предоставляет необходимые службы запроса метаданных аутентификации и авторизации, а также управления ими для компонента Proxy.

Конфигурация кластера

Конфигурация аутентификации

список параметров

Если вы хотите включить функцию аутентификации на стороне сервера, соответствующие параметры и варианты использования в основном включают следующее:

Конфигурация брокера

authenticationEnabled = true
authenticationProvider = org.apache.rocketmq.auth.authentication.provider.DefaultAuthenticationProvider
initAuthenticationUser = {"username":"rocketmq","password":"12345678"}
innerClientAuthenticationCredentials = {"accessKey":"rocketmq","secretKey":"12345678"}
authenticationMetadataProvider = org.apache.rocketmq.auth.authentication.provider.LocalAuthenticationMetadataProvider

Конфигурация прокси

{
  "authenticationEnabled": true,
  "authenticationProvider": "org.apache.rocketmq.auth.authentication.provider.DefaultAuthenticationProvider",
  "authenticationMetadataProvider": "org.apache.rocketmq.proxy.auth.ProxyAuthenticationMetadataProvider",
  "innerClientAuthenticationCredentials": "{\"accessKey\":\"rocketmq\", \"secretKey\":\"12345678\"}"
}

Настройка авторизации

список параметров

Если вы хотите включить функцию авторизации на стороне сервера, соответствующие параметры и варианты использования в основном включают следующее:

Конфигурация брокера

authorizationEnabled = true
authorizationProvider = org.apache.rocketmq.auth.authorization.provider.DefaultAuthorizationProvider
authorizationMetadataProvider = org.apache.rocketmq.auth.authorization.provider.LocalAuthorizationMetadataProvider

Конфигурация прокси

{
  "authorizationEnabled": true,
  "authorizationProvider": "org.apache.rocketmq.auth.authorization.provider.DefaultAuthorizationProvider",
  "authorizationMetadataProvider": "org.apache.rocketmq.proxy.auth.ProxyAuthorizationMetadataProvider"
}

как использовать

Использование командной строки

Управление пользователями

Что касается управления пользователями ACL, соответствующие определения интерфейса и варианты использования следующие.

Определение интерфейса

Случаи использования

# 创建用户
sh mqadmin createUser -n 127.0.0.1:9876 -c DefaultCluster -u rocketmq -p rocketmq
# 创建用户，指定用户类型
sh mqadmin createUser -n 127.0.0.1:9876 -c DefaultCluster -u rocketmq -p rocketmq -t Super
# 更新用户
sh mqadmin updateUser -n 127.0.0.1:9876 -c DefaultCluster -u rocketmq -p 12345678
# 删除用户
sh mqadmin deleteUser -n 127.0.0.1:9876 -c DefaultCluster -u rocketmq
# 查询用户详情
sh mqadmin getUser -n 127.0.0.1:9876 -c DefaultCluster -u rocketmq
# 查询用户列表
sh mqadmin listUser -n 127.0.0.1:9876 -c DefaultCluster
# 查询用户列表，带过滤条件
sh mqadmin listUser -n 127.0.0.1:9876 -c DefaultCluster -f mq

Управление ACL

Что касается управления авторизацией ACL, соответствующие определения интерфейса и варианты использования следующие.

Определение интерфейса

Случаи использования

# 创建授权
sh mqadmin createAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq -r Topic:*,Group:* -a Pub,Sub -i 192.168.1.0/24 -d Allow
# 更新授权
sh mqadmin updateAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq -r Topic:*,Group:* -a Pub,Sub -i 192.168.1.0/24 -d Deny
# 删除授权
sh mqadmin deleteAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq
# 删除授权，指定资源
sh mqadmin deleteAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq -r Topic:*
# 查询授权列表
sh mqadmin listAcl -n 127.0.0.1:9876 -c DefaultCluster
# 查询授权列表，带过滤条件
sh mqadmin listAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq -r Topic:*
# 查询授权详情
sh mqadmin getAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq

Использование клиента

Что касается использования ACL, ACL 2.0 и ACL 1.0 используются одинаково без каких-либо различий. Подробности см. в официальном случае.

отправка сообщения

ClientServiceProvider provider = ClientServiceProvider.loadService();
StaticSessionCredentialsProvider sessionCredentialsProvider = 
  new StaticSessionCredentialsProvider(ACCESS_KEY, SECRET_KEY);
ClientConfiguration clientConfiguration = ClientConfiguration.newBuilder()
    .setEndpoints(ENDPOINTS)
    .setCredentialProvider(sessionCredentialsProvider)
    .build();
Producer producer = provider.newProducerBuilder()
    .setClientConfiguration(clientConfiguration)
    .setTopics(TOPICS)
    .build();

Потребление сообщений

ClientServiceProvider provider = ClientServiceProvider.loadService();
ClientConfiguration clientConfiguration = ClientConfiguration.newBuilder()
    .setEndpoints(ENDPOINTS)
    .setCredentialProvider(sessionCredentialsProvider)
    .build();
FilterExpression filterExpression = new FilterExpression(TAG, FilterExpressionType.TAG);
PushConsumer pushConsumer = provider.newPushConsumerBuilder()
    .setClientConfiguration(clientConfiguration)
    .setConsumerGroup(CONSUMER_GROUP)
    .setSubscriptionExpressions(Collections.singletonMap(TOPIC, filterExpression))
    .setMessageListener(messageView -> {
        return ConsumeResult.SUCCESS;
    })
    .build();

Расширение и миграция

Расширение

Если вы хотите расширить брокер во время работы кластера, вам необходимо синхронизировать все метаданные с новым брокером ACL 2.0, который предоставляет соответствующие интерфейсы копирования пользователя и авторизации копирования для поддержки этой операции.

Определение интерфейса

Случаи использования

# 拷贝用户
sh mqadmin copyUser -n 127.0.0.1:9876 -f 192.168.0.1:10911 -t 192.168.0.2:10911
# 拷贝授权
sh mqadmin copyAcl -n 127.0.0.1:9876 -f 192.168.0.1:10911 -t 192.168.0.2:10911

мигрировать

Если вы уже используете ACL 1.0 и хотите плавно перейти на ACL 2.0, вам также предоставляются соответствующие решения. Вам нужно всего лишь выполнить следующие настройки.

Определение конфигурации

Включите следующую конфигурацию в файле конфигурации брокера:

migrateAuthFromV1Enabled = true

Специальная записка

После включения вышеуказанной конфигурации выполнение будет автоматически запускаться во время запуска брокера. Эта функция миграции запишет информацию о разрешениях пользователя из ACL 1.0 в соответствующую структуру хранения ACL 2.0.

Пользователи и разрешения, которых еще нет в ACL 2.0, будут добавлены системой автоматически. Функция миграции не будет перезаписывать существующих пользователей и разрешения, чтобы избежать перезаписи любых изменений, внесенных в ACL 2.0.

Белый список IP-адресов в ACL 1.0 используется для обхода проверок контроля доступа и не соответствует поведению ACL 2.0, поэтому он не будет перенесен в ACL 2.0. Если вы уже использовали соответствующие возможности, завершите преобразование перед миграцией.

Планирование и заключение

планирование

Будущее планирование RocketMQ ACL может быть отражено в следующих двух аспектах:

Расширенные возможности аутентификации и авторизации : на рынке существуют богатые решения для аутентификации и авторизации, а другие продукты хранения или вычисления также используют различные методы реализации. Чтобы идти в ногу с тенденциями развития отрасли, RocketMQ ACL также будет стремиться к инновациям в будущем для удовлетворения более широких и меняющихся потребностей клиентов. В то же время мы продолжим углублять исследования и разрабатывать более эффективные стратегии аутентификации и авторизации для достижения идеального баланса между безопасностью и производительностью.
Визуальные операции с разрешениями пользователей . В настоящее время пользователей и разрешения можно настроить только в ACL с помощью инструментов командной строки, что недостаточно удобно для пользователя. В будущем мы надеемся предоставить понятный и простой в использовании интерфейс визуального управления на RocketMQ Dashboard, тем самым упрощая процесс настройки и снижая технический порог управления. С другой стороны, существующая Dashboard еще не интегрировала систему контроля доступа ACL, которая также будет встроена в будущем, чтобы предоставить пользователям права доступа для управления различными ресурсами на Dashboard.

Подведем итог

RocketMQ ACL 2.0 претерпел совершенно новые обновления с точки зрения дизайна модели, масштабируемости, безопасности и производительности. Он разработан, чтобы предоставить пользователям более совершенный контроль доступа, одновременно упрощая процесс настройки разрешений. Приглашаем всех желающих опробовать новую версию и применить ее в производственной среде. Мы с нетерпением ждем отзывов, обсуждений и участия каждого в сообществе, чтобы совместно способствовать росту и технологическому прогрессу сообщества RocketMQ. Добро пожаловать в группу DingTalk китайских разработчиков Apache RocketMQ. (Номер группы: 21982288)

Ссылки по теме:

[1] Веб-сайт RocketMQ по изучению китайского языка ttps://rocketmq-learning.com

[2] Очередь облачных сообщений RocketMQ https://www.aliyun.com/product/rocketmq