Агент Elasticsearch

Агент Elasticsearch — это сервис рядом с кластером. Он поддерживает собственный контроль доступа Elasticsearch в соответствии с подписанными политиками сервиса данных elasticsearch: одна роль на пользователя, которая содержит ровно то, что ему дают политики, с безопасностью на уровне полей и документов там, где её даёт лицензия кластера. Внутренний (native) пользователь носит роль среди собственных ролей; пользователь другой области (realm), например LDAP, SAML или OpenID Connect, получает её через сопоставление ролей по своему имени. Затем Elasticsearch сам проверяет каждый запрос, а агент никогда не стоит между клиентами и кластером. Дистрибутив поставляет его как исполняемый JAR agents/elasticsearch/grantforge-agent-elasticsearch-<version>.jar, которому нужна Java 17 или новее.

Интеграционные тесты Testcontainers в репозитории запускают агент и поставляемый JAR на Elasticsearch 8.19, 9.3, 9.4 и 9.5 с включённой безопасностью. Это не означает сертификацию всех остальных версий; агент отклоняет кластеры старше 8.19, кластеры без безопасности и кластеры OpenSearch, которые ведёт агент OpenSearch. О сервисном плагине см. Elasticsearch.

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

• Одна роль на пользователя содержит то, что даёт GrantForge. Для каждого пользователя, которому политики что-то дают, агент ведёт роль с его именем, grantforge_alice для alice. Её метаданные называют пользователя и помечают роль как роль агента, и агент не считает своей ни одну роль без этой метки, поэтому не меняет никаких других ролей.
• Внутренние пользователи носят роль; другие области получают её по имени. Агент добавляет роль к ролям внутреннего пользователя и сохраняет все остальные его роли. Сопоставления ролей действуют во всех областях, кроме внутренней и файловой, поэтому агент ведёт также одноимённое сопоставление ролей, которое выдаёт роль имени пользователя, — для пользователей, входящих через LDAP, Active Directory, SAML, OpenID Connect, JWT, Kerberos или PKI. Файловую область нельзя изменить через API Elasticsearch; её пользователи роль не получают.
• Шаблоны индексов остаются шаблонами. Шаблон индекса из политики, например logs-*, выдаётся как шаблон там, где все политики решают одинаково по всему шаблону: любая политика любого вида, чьи индексы пересекаются с шаблоном, покрывает его целиком. Агент решает это точно, с помощью конечных автоматов шаблонов. Индексы, созданные позже, например завтрашние журналы, тогда сразу доступны, в том числе когда их создаёт первый записанный документ. Где политика внутри шаблона решает иначе, например запрет logs-secret внутри logs-*, агент выдаёт каждый индекс и поток данных кластера по имени, а новые — при следующей синхронизации.
• Безопасность на уровне полей — только где ниже решается иначе. Индекс, который пользователь может читать целиком и где ни одна политика не может отнять поле, читается без безопасности на уровне полей, поэтому поля, добавленные позже, читаются сразу. Иначе пользователь читает поля, которые разрешает политика, из тех, что есть в его документах и что названы в политиках, каждое вместе с мультиполями, например name.keyword вместе с name.
• Фильтры строк — это безопасность на уровне документов. Фильтр строк становится запросом записи. API validate Elasticsearch проверяет каждый запрос до выдачи; запрос, который Elasticsearch не выполнил бы, не показывает пользователю ни одного документа и записывается в журнал.
• Ниже Platinum — никогда больше, чем разрешают политики. Безопасность на уровне документов и полей есть в Elasticsearch начиная с лицензии Platinum, а ниже неё он отключает любую роль, которая её использует. Агент читает лицензию при каждой синхронизации. Ниже Platinum чтение, которому нужна любая из них, потому что политика ограничивает поля или документы индекса, не выдаётся вовсе, и агент записывает в журнал, какой пользователь не может читать какой индекс и почему; чтение целых индексов и всё остальное выдаётся как обычно.
• Одна запись на набор привилегий. Индексы и шаблоны с одинаковыми привилегиями делят одну запись; записи никогда не пересекаются, поскольку Elasticsearch объединяет безопасность на уровне полей и документов пересекающихся записей.
• Политики текущего момента. Каждая синхронизация планирует по политикам в том виде, в каком они действуют в этот момент, поэтому сроки действия начинаются и заканчиваются вовремя.
• Роли внутренних пользователей — это группы. Политика для группы действует для внутренних пользователей, у которых есть роль с таким именем, вместе с группами, в которые GrantForge помещает пользователей.
• Ручные изменения отменяются. При каждой синхронизации агент сравнивает свои роли, сопоставления ролей и роли внутренних пользователей с тем, что хранит Elasticsearch; отличия записываются заново, а роль одного пользователя, которую носит другой, отбирается. Роли записываются до выдачи, одним запросом, и отбираются до удаления. Если ничего не изменилось, агент ничего не отправляет; изменение, которое Elasticsearch отклоняет, записывается в журнал и не останавливает остальные.
• Роли вне GrantForge сообщаются. Elasticsearch выдаёт то, что даёт любая из ролей пользователя, поэтому агент не может отнять то, что даёт другая роль. Он однократно предупреждает о каждой такой роли, которую носит внутренний пользователь или выдаёт сопоставление ролей по его имени, и которая даёт то, что запрещает политика, называя роль, пользователя, доступ, индекс и политику, а также о пользователях с ролью superuser, которых не ограничивает ни одна роль.
• Обращения берутся из файлов журнала аудита. Elasticsearch пишет журнал аудита только в файл на каждом узле. Агент читает указанные ему файлы с того места, где закончилось последнее чтение, следует за ними при ротации и сообщает события access_granted и access_denied. Каждое событие называет пользователя, тип доступа, каждый затронутый индекс или поток данных либо кластер и сообщает, решил ли это GrantForge или разрешила роль вне GrantForge.

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

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

2. Дайте агенту пользователя с кластерной привилегией manage_security, которая управляет ролями, сопоставлениями ролей и пользователями, и с правом читать отображения каждого индекса и проверять запросы, например пользователя с ролью superuser. Он может входить по паролю, по API-ключу, созданному этим пользователем, или по клиентскому сертификату, который область PKI сопоставляет с ним.

3. Чтобы сообщать об обращениях, включите журнал аудита (xpack.security.audit.enabled: true), для которого нужна лицензия Gold или выше, и дайте агенту читать файлы аудита узлов, <имя кластера>_audit.json в каталоге журналов каждого узла: запустите агент на узле или соберите файлы в каталог, который он может читать. xpack.security.audit.logfile.events.include: access_granted, access_denied ограничивает журнал тем, о чём сообщает агент.

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

   grantforge.server.url=https://grantforge.example.com
   grantforge.token.file=/etc/grantforge/elasticsearch-agent.token
   grantforge.instance=elasticsearch-agent-1
   grantforge.cache.dir=/var/lib/grantforge/elasticsearch-agent
   grantforge.elasticsearch.hosts=https://es1.internal:9200,https://es2.internal:9200
   grantforge.elasticsearch.user=grantforge
   grantforge.elasticsearch.password.file=/etc/grantforge/elasticsearch-agent.password
   grantforge.elasticsearch.tls.ca=/etc/grantforge/http_ca.crt
   grantforge.audit.log.files=/var/log/elasticsearch/production_audit.json

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

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

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

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

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

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

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

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

• Без снимка агент ничего не меняет. Неиспользуемый сервис или токен, привязанный к сервису с типом не elasticsearch, ничего не выдают: агент отбирает свои роли и удаляет их вместе с сопоставлениями ролей, и действуют собственные роли Elasticsearch.
• Пока агент не работает, Elasticsearch сохраняет то, что получил последним; изменения политик ждут агента. Изменение доходит до Elasticsearch в пределах интервала обновления и интервала синхронизации.
• Индексы, выданные по имени, а не через шаблон, получают привилегии при следующей синхронизации.
• Ниже Platinum пользователь, чтение индекса которым ограничивает политика, не читает из него ничего; ниже Gold агент не сообщает об обращениях.
• Сопоставление ролей по имени пользователя действует в каждой области с таким именем пользователя; политики называют пользователей, а не области.
• Псевдонимы ведут к индексам за ними, поэтому политики называют индексы и потоки данных, а не псевдонимы. Индексы, имена которых начинаются с точки, доступны только через шаблоны политик, начинающиеся с точки.
• Пространства (spaces) и привилегии приложений Kibana агент не ведёт.

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

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