elasticsearch-authn

Elasticsearch Authentication — навык для подключения к уже настроенному кластеру Elasticsearch, выбора подходящего authentication realm и управления API keys. Он рассматривает native и file realms, LDAP, Active Directory, PKI с клиентскими сертификатами, SAML, OIDC, JWT и Kerberos, а также отдельный механизм API key для программного доступа. Предполагается, что сами realms и их identity backends уже настроены; навык не заменяет конфигурацию кластера или внешнего провайдера удостоверений. Базовые входные данные — URL кластера Elasticsearch и credentials, зависящие от выбранного способа. Примеры используют ELASTICSEARCH_URL, ELASTICSEARCH_API_KEY, ELASTICSEARCH_USERNAME и ELASTICSEARCH_PASSWORD или realm-specific переменные. Секреты нельзя просить вставить в чат, выводить в логи или хранить в коде и репозитории. Источник рекомендует держать значения в .env проекта и передавать их через переменные окружения; это особенно важно, когда агент работает в отдельной shell-сессии. Перед операциями управления нужно проверить identity запросом GET /_security/_authenticate или тем же endpoint через curl. Ответ _authenticate позволяет сверить username, roles и authentication_realm.type. В таблице навыка перечислены значения native, file, ldap, active_directory, pki, saml, oidc, jwt и kerberos; для API key используется authentication_type со значением api_key, а не realm type. Native удобен для интерактивной работы, file может быть fallback для disaster recovery на self-managed, LDAP и AD подходят для корпоративного каталога, PKI — для service-to-service mutual TLS, а SAML и OIDC предназначены прежде всего для браузерного SSO через Kibana. JWT рассчитан на bearer-токены внешнего issuer, Kerberos — на окружения с KDC, DNS и синхронизацией времени. Для автоматизации источник предпочитает API keys с ограниченными правами и сроком действия. При создании можно передать role_descriptors с нужными cluster- и index-привилегиями, например только read для заданного index pattern, и expiration. В ответе возвращаются id, api_key и encoded; encoded нужно сохранить безопасно, потому что повторно получить его нельзя. Существующий ключ можно найти по имени и инвалидировать DELETE-запросом. Важное ограничение: API key не должен создавать другой API key с привилегиями; для выдачи ключа от имени пользователя используется POST /_security/api_key/grant с пользовательскими credentials. Для production не следует применять indefinite keys, unscoped automation keys или superuser. Выбор метода зависит от deployment. Self-managed поддерживает все перечисленные realms. В Elastic Cloud Hosted нет node-level доступа, поэтому file realm и elasticsearch-users недоступны, а LDAP, AD и Kerberos не настраиваются; PKI имеет ограниченную поддержку, SAML, OIDC и JWT задаются настройками deployment. В Serverless API keys являются основным способом доступа, native users не существуют на уровне проекта, SAML настраивается на уровне организации, а file, LDAP, AD, PKI, OIDC, JWT и Kerberos недоступны в таблице совместимости источника. Для SAML и OIDC нужен companion realm для REST API. Навык рассчитан на curl или другой HTTP-клиент и сетевой доступ к endpoint. Он помогает не только выполнить первый login, но и подтвердить фактически сработавший realm, создать scoped key, организовать rotation или invalidation и выбрать безопасный вариант для CI/CD. Управление ролями, пользователями, role mappings и RBAC вынесено в отдельный elasticsearch-authz skill; authentication skill ограничивается проверкой личности, способом входа и lifecycle ключей.