Агент Apache Solr

Агент Solr — плагин авторизации узлов: Solr спрашивает его о каждом запросе, и он отвечает по подписанным политикам сервиса данных solr. Дистрибутив поставляет его одним JAR-файлом Java 11, agents/solr/grantforge-agent-solr-<version>.jar, со встроенными и перемещёнными зависимостями.

Интеграционные тесты Testcontainers в репозитории запускают JAR внутри узлов SolrCloud версий Solr 9.8.1, 9.10.1, 9.11.0 и 10.0.0. Это не означает сертификацию всех остальных версий. Плагин сервиса описан в Apache Solr.

Как это работает

• Запросы классифицируются так же, как их классифицирует Solr. Каждый обработчик запросов называет нужное ему право, например read или collection-admin-edit, как и для собственного плагина правил Solr; агент превращает это имя в тип доступа, а обработчик, который ничего не называет, решается по типу запроса.
• Каждый запрос к коллекции решается и на её пути запроса. Агент решает запрос к sales через /select на коллекции sales и на sales с путём /select: запрет на любом из них отклоняет запрос, так что политика может запретить один обработчик коллекции.
• Команды администрируют свои коллекции. Запросу Collections API, называющему коллекции, нужен admin_collection на каждой из них, поэтому политика может разрешить команде создавать, перезагружать или удалять только коллекции с её префиксом.
• Администраторы кластера могут всё. admin на кластере разрешает любой запрос, как собственное право Solr all.
• Политики могут действовать только для некоторых сетей. Каждая проверка несёт адрес клиента; за обратными прокси, которым доверяет агент, клиент — это последний адрес в X-Forwarded-For, добавленный не доверенным прокси.
• Проверенные роли JSON Web Token считаются группами. При JWT-аутентификации Solr роли, которые утверждение токена даёт пользователю, становятся группами решения наряду с группами, в которые GrantForge включает пользователя.
• Отказы записываются в журнал с причиной. Solr отвечает на отклонённый запрос своим 403; журнал узла называет политику GrantForge, которая его запретила, или сообщает, что ни одна его не разрешает.
• Решения кэшируются, обращения объединяются. Решения текущего снимка хранятся, по умолчанию 100 000 на 10 секунд, а новый снимок начинает заново. Одинаковые разрешённые обращения в пределах окна, по умолчанию 10 секунд, передаются одним событием доступа с их количеством; отказы передаются по одному и сразу. Каждое событие называет коллекцию и путь или кластер, а также адрес клиента.
• Узлы не проверяются. Запросы между узлами, которые Solr подписывает от имени самого узла, пропускаются; запрос без пользователя получает требование войти.

Развёртывание

1. Добавьте сервис данных solr и настройте его политики, включая admin на кластере для администраторов Solr. Откройте Права доступа к данным → Агенты, выберите сервис и выпустите токен агента. Он показывается только один раз; сохраните его в файл, доступный для чтения только учётной записи Solr.

2. Скопируйте JAR в server/solr-webapp/webapp/WEB-INF/lib каждого узла, например /opt/solr/server/solr-webapp/webapp/WEB-INF/lib, и перезапустите узлы по одному.

3. Задайте раздел авторизации в security.json кластера рядом с плагином аутентификации, заменив адрес, пути и имя экземпляра из примера:

   {
     "authentication": {
       "class": "solr.BasicAuthPlugin",
       "blockUnknown": true,
       "credentials": { "solr": "<salted SHA-256 hash> <salt>" }
     },
     "authorization": {
       "class": "org.devlive.grantforge.solr.agent.GrantForgeSolrAuthorizer",
       "grantforge.server.url": "https://grantforge.example.com",
       "grantforge.token.file": "/var/solr/data/grantforge.token",
       "grantforge.instance": "solr-cluster",
       "grantforge.cache.dir": "/var/solr/data/grantforge-cache"
     }
   }

   Загрузите его командой bin/solr zk cp file:security.json zk:/security.json -z <zookeeper>; узлы применяют его без перезапуска. Аутентификация должна быть включена, чтобы у запросов были пользователи.

4. В Solr 9 учтите менеджер безопасности Java, который Solr включает по умолчанию: храните токен, закреплённый ключ и каталог кэша внутри SOLR_HOME, например /var/solr/data, и выдайте агенту то, что ему нужно сверх политики Solr, в server/etc/security.policy или в собственном файле политики, который -Djava.security.properties добавляет как policy.url.3:

   grant {
     permission java.security.SecurityPermission "getProperty.org.devlive.grantforge.solr.agent.internal.bouncycastle.*";
   };

   Solr 10 работает без менеджера безопасности.

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

Пользователи, группы и роли

Политики называют пользователя, которого удостоверяет аутентификация Solr, например пользователя basic-аутентификации или субъект JSON Web Token. Группы — это роли, которые JSON Web Token подтвердил для пользователя, вместе с группами, в которые GrantForge включает пользователя; роли — это роли, которые GrantForge выдаёт пользователю.

Решения и ограничения

• Без пригодного снимка отклоняется всё, кроме запросов между узлами. Неиспользуемый сервис оставляет Solr без проверок, как без плагина авторизации.
• Токен, привязанный к сервису с типом не solr, отклоняет всё.
• Запрос Collections API, который называет свои коллекции только в теле JSON, как некоторые запросы API v2, не называет ни одной видимой агенту коллекции, и ему нужен admin на кластере.
• Solr разрешает псевдонимы в коллекции до того, как спросить, поэтому политики называют коллекции, а не псевдонимы.
• API Solr /admin/authorization не может изменять правила агента: политики хранит GrantForge.
• Адреса клиентов — только адреса и диапазоны; имя хоста ничему не соответствует.
• Решения хранятся grantforge.decision.cache.ttl.ms, поэтому политика начинает или перестаёт действовать с задержкой до этого времени.

Связанные руководства

• Apache Solr
• Сервисы данных, политики и агенты