elasticsearch-authz

elasticsearch-authz — официальный навык Elastic для проектирования и управления авторизацией в Elasticsearch. Он охватывает native users, роли, role mappings и сценарии, где внешние пользователи приходят из LDAP, SAML или PKI. Его задача — перевести запрос о доступе на язык конкретного пользователя, набора индексов, уровня привилегий и границ видимости данных, а затем выбрать безопасную последовательность операций. Навык применим к созданию пользователя, least-privilege роли, сопоставлению атрибутов внешнего realm и настройке доступа к Kibana feature или space. Перед изменением нужно собрать контекст: кто получает доступ, какие индексы или data streams затрагиваются, требуется ли чтение, запись или управление, видны ли все документы и поля, нужна ли Kibana и какой тип deployment используется. Для управления пользователями и ролями нужен cluster privilege manage_security; для Kibana feature и space privileges необходимы соответствующие права в Stack Management. Если не хватает Elasticsearch URL, Kibana URL или способа аутентификации, навык требует сначала запросить недостающие значения, а не строить конфигурацию по догадке. Рабочий процесс начинается с проверки существующих ролей. Если подходящая роль уже даёт требуемый доступ, её следует переиспользовать, чтобы не плодить почти одинаковые разрешения. Если роли нет, описываются cluster privileges, index privileges, patterns индексов и, при необходимости, Kibana privileges. Для ограничения строк применяются document-level security, для скрытия чувствительных полей — field-level security. Транслируемые атрибуты внешнего пользователя могут участвовать в ABAC через templated role queries и Mustache; это позволяет выразить границу доступа, но требует проверки реальных атрибутов и результата запроса. Навык разделяет авторизацию и соседние задачи. Для authentication methods и API key management он направляет к отдельному elasticsearch-authn, а детали REST endpoints вынесены в reference-файлы исходного репозитория. Self-managed, Elastic Cloud Hosted и Serverless имеют различия в доступных возможностях и модели назначения прав, поэтому одну и ту же роль нельзя считать переносимой без сверки deployment compatibility. Пользовательские, ролевые и mapping-операции нужно выполнять через подтверждённый endpoint и с корректными правами, сохраняя принцип минимально необходимого доступа. Практические сценарии включают read-only доступ к logs-*, разграничение отделов по атрибуту, роль для Kibana space, ограничение PII и проверку роли после изменения mapping. Ограничения также являются частью результата: описание не выдаёт credentials, не гарантирует конкретную совместимость версии и не заменяет тест чтения, записи и видимости документов в целевом окружении. Итогом должна быть проверяемая модель «кто — что — где — каким способом», а не просто созданная запись пользователя.