Агент MongoDB

Агент MongoDB — это сервис рядом с развёртыванием. Он поддерживает собственное управление доступом MongoDB в соответствии с подписанными политиками сервиса данных mongodb: одна роль на пользователя, содержащая ровно то, что ему дают политики. Затем MongoDB сам проверяет каждую команду, а агент не стоит на пути ни одного клиента. Дистрибутив поставляет его как исполняемый JAR agents/mongodb/grantforge-agent-mongodb-<version>.jar; нужна Java 17 или новее.

Интеграционные тесты Testcontainers в репозитории запускают агента и поставляемый JAR на наборах реплик MongoDB 6.0, 7.0, 8.0 и 9.0 и шардированном кластере 9.0 и читают журнал аудита Percona Server for MongoDB 7.0 и 8.0. Это не сертифицирует все остальные версии; агент отклоняет развёртывания старше 6.0. О сервисном плагине см. MongoDB.

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

• Одна роль на пользователя содержит то, что даёт GrantForge. Для каждого пользователя, которому политики что-то дают, агент поддерживает в admin роль с его именем, grantforge_alice для alice, и выдаёт её каждому пользователю MongoDB с этим именем, например alice@admin и alice@sales. rolesInfo показывает, что GrantForge даёт alice. Другие роли агент не меняет.
• Изменение происходит за один шаг. updateRole заменяет привилегии роли разом, так что у пользователя никогда не бывает одновременно старых и новых или ни тех, ни других.
• Целые базы данных там, где ниже ничего не решается иначе. Тип доступа, который политика разрешает на всю базу данных и который ни одна политика не может отнять ниже, выдаётся на базу, так что коллекции, созданные позже, получают его сразу. Иначе он выдаётся по коллекциям, а новые охватываются при следующей синхронизации.
• Никогда больше, чем разрешают политики. Привилегия MongoDB на удаление базы данных — это привилегия на удаление каждой её коллекции. Агент выдаёт её только там, где политики дают и это; иначе не выдаёт и один раз записывает в журнал, какой пользователь чего не может и почему.
• Политики текущего момента. Каждая синхронизация планирует по политикам, действующим в этот момент, так что сроки действия начинаются и заканчиваются вовремя, и по пользователям, базам данных и коллекциям, которые есть в MongoDB, так что новые охватываются при следующей синхронизации.
• Роли MongoDB — это группы. Политика для группы применяется к пользователям с ролью MongoDB с таким именем, а также к группам, в которые их помещает GrantForge.
• Ручные изменения отменяются. При каждой синхронизации агент сравнивает свои роли с планами и исправляет привилегии, изменённые вручную, роли, которые заставили их наследовать, выдачу роли кому-то другому и роли, которые никому не нужны. Если ничего не изменилось, он ничего не отправляет.
• Роли вне GrantForge читаются на предмет того, что они дают. MongoDB суммирует то, что дают все роли пользователя, поэтому агент не может отнять то, что у пользователя есть через другую роль. MongoDB сообщает, что даёт каждая роль, включая встроенные и унаследованные, поэтому агент по одному разу предупреждает о роли вроде readWrite@hr, дающей то, что запрещает политика, называя пользователя, доступ и политику. Он также предупреждает о пользователях, которые могут администрировать пользователей и так выдать себе что угодно, о пользователях с root или любым действием на любом ресурсе и о сервере, который вообще не проверяет авторизацию.
• Доступ берётся из журнала аудита или профилировщика. См. раздел «Сообщения о доступе» ниже. Каждое событие сообщает, решил ли GrantForge, то есть решают ли политики так же, как MongoDB, или команду разрешила внешняя роль. Об агрегации сообщается для каждой коллекции, которую читают её стадии $lookup, $graphLookup и $unionWith и записывают $out и $merge. События называют команду и её пространство имён, но никогда её аргументы, которые могут содержать документы и пароли.

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

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

2. Создайте пользователя MongoDB для агента. Он создаёт и меняет роли и читает пользователей и роли с помощью userAdminAnyDatabase; перечисляет коллекции с помощью роли, которая содержит только это; и читает параметры сервера и профилировщик с помощью clusterMonitor. userAdminAnyDatabase может выдать себе что угодно, поэтому защищайте этого пользователя как администратора. Имя роли для перечисления не должно начинаться с префикса ролей агента.

   const admin = db.getSiblingDB("admin");
   admin.createRole({ role: "agent_inventory", roles: [],
     privileges: [{ resource: { db: "", collection: "" }, actions: ["listCollections"] }] });
   admin.createUser({ user: "grantforge", pwd: passwordPrompt(),
     roles: ["userAdminAnyDatabase", "clusterMonitor", "agent_inventory"] });

3. Чтобы сообщать о доступе, настройте один из источников из раздела «Сообщения о доступе» ниже.

4. Напишите файл параметров, заменив примерные адреса, пути и имена:

   grantforge.server.url=https://grantforge.example.com
   grantforge.token.file=/etc/grantforge/mongodb-agent.token
   grantforge.instance=mongodb-agent-1
   grantforge.cache.dir=/var/lib/grantforge/mongodb-agent
   grantforge.mongodb.uri=mongodb://db1.internal:27017,db2.internal:27017/?replicaSet=rs0
   grantforge.mongodb.user=grantforge
   grantforge.mongodb.password.file=/etc/grantforge/mongodb-agent.password

   Эти пути находятся на машине агента, а каталог кэша должен быть доступен для записи. Файлы паролей читаются в UTF-8 с обрезкой пробелов.

5. Запустите агент, например как службу systemd:

   java -jar agents/mongodb/grantforge-agent-mongodb-<version>.jar /etc/grantforge/mongodb-agent.properties

   Замените <version> версией дистрибутива. Параметры, переданные как java -Dgrantforge.…=… -jar …, переопределяют файл. По SIGTERM агент корректно останавливается и отправляет или откладывает ожидающие события; MongoDB сохраняет то, что получил.

6. Перенос существующих привилегий в политики: роли, выданные вне GrantForge, продолжают действовать рядом с ролями агента. Создайте соответствующие политики, затем отзовите эти роли. Предупреждения агента указывают на те, что дают запрещённое политикой.

Сообщения о доступе

Журнал аудита читается из файлов, поэтому запускайте агента на узле или дайте ему каталог, в котором они собираются. Тесты читают журнал аудита Percona Server, имеющий формат MongoDB Enterprise. У mongos нет профилировщика, поэтому шардированный кластер сообщает о доступе только из журнала аудита.

MongoDB отклоняет команду целиком, не говоря, какая из её коллекций стала причиной, поэтому об отказе сообщается для тех, которые запрещают политики, или для первой, если они не запрещают ни одной.

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

Политики называют пользователей MongoDB по имени пользователя. Имя, определённое в нескольких базах данных, — это один пользователь, и роль агента выдаётся всем им. Группы — это роли MongoDB пользователя и группы, в которые его помещает GrantForge. Роли — это роли, которые GrantForge даёт пользователю.

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

• Без снимка агент ничего не меняет. Токен, привязанный к неиспользуемому сервису или к сервису не типа mongodb, ничего не выдаёт: агент удаляет свои роли, а собственные роли MongoDB остаются.
• Пока агент не работает, MongoDB сохраняет полученное последним, а изменения политик ждут. Изменение доходит до MongoDB в пределах интервалов обновления и синхронизации; mongos применяет его, когда истечёт его кэш пользователей, по умолчанию в течение 30 секунд (userCacheInvalidationIntervalSecs).
• Привилегии MongoDB точно называют базы данных и коллекции, поэтому подстановочный знак в политике выдаётся для того, что существует. База данных существует, когда в ней есть коллекция: до этого create на базу, названную в политике, выдавать не на что.
• Пользователи, нигде не определённые в MongoDB, например те, кого авторизация LDAP сама сопоставляет с ролями, не видны, и агент не поддерживает для них ролей.
• Привилегия на всю базу данных охватывает её коллекции, но не коллекции system., а собственные базы MongoDB остаются за MongoDB.
• Переименование коллекций и прочие административные действия MongoDB не являются типами доступа: они остаются за ролями вне GrantForge.
• MongoDB не фильтрует строки и не маскирует поля по ролям; представление даёт ограниченное чтение.

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

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