Документация Grafana Документация GlaberGraph Настройка Настройка управления доступом Настройка аутентификации

Настройка аутентификации

Grafana предоставляет множество способов аутентификации пользователей. Некоторые интеграции аутентификации также позволяют синхронизировать разрешения пользователей и членство в организациях.

В следующей таблице показаны все поддерживаемые методы аутентификации и доступные для них функции. Синхронизация команд, активная синхронизация и SAML доступны в Grafana Enterprise и Grafana Cloud. Они недоступны в Grafana с открытым исходным кодом.

Пояснения к полям:

Multi Org Mapping: Возможность добавить пользователя и сопоставить роли с несколькими организациями

Enforce Sync: Если информация, предоставленная провайдером идентификации, пуста, пропускает ли интеграция установку этого поля пользователя или применяет значение по умолчанию.

Role Mapping: Возможность сопоставить роль пользователя в организации по умолчанию

Grafana Admin Mapping: Возможность сопоставить административную роль пользователя в организации по умолчанию

Team Sync: Возможность синхронизировать команды из предопределённой группы/команды в вашем IdP

Allowed Groups: Разрешать вход только членам определённых групп

Active Sync: Добавлять пользователей в команды и обновлять их профиль без необходимости входа в систему

Skip OrgRole Sync: Возможность изменять роль в организации для пользователей и не синхронизировать её обратно в IdP

Auto Login: Автоматически перенаправляет на страницу входа провайдера, если пользователь не вошёл в систему * для OAuth; работает только если это единственный настроенный провайдер

Single Logout: Выход из Grafana также завершает сессию в провайдере

SCIM support: Поддержка провижининга SCIM. Поддерживаемые провайдеры идентификации — Entra ID и Okta.

Настройка нескольких провайдеров идентификации

Grafana позволяет настроить более одного провайдера аутентификации, однако невозможно настроить один и тот же тип провайдера аутентификации дважды. Например, вы можете иметь настроенными SAML (Enterprise и Cloud) и Generic OAuth, но не можете иметь две разные конфигурации Generic OAuth.

Примечание: Grafana не поддерживает несколько провайдеров идентификации, разрешающих одного и того же пользователя. Убедитесь, что учётные записи пользователей не пересекаются между разными провайдерами.

В сценариях, когда у вас есть несколько провайдеров идентификации одного типа, есть несколько вариантов:

• Использовать разные экземпляры Grafana, каждый из которых настроен с данным провайдером идентификации.
• Проверить, поддерживает ли провайдер идентификации федерацию учётных записей. В таких случаях вы можете настроить его один раз и позволить вашему провайдеру идентификации федератировать учётные записи от разных провайдеров.
• Если провайдер идентификации поддерживает SAML, вы можете настроить один Generic OAuth и один SAML (Enterprise и Cloud).

Использование одного и того же адреса электронной почты для входа через разных провайдеров идентификации

Если пользователи хотят использовать один и тот же адрес электронной почты с несколькими провайдерами идентификации (например, Grafana.Com OAuth и Google OAuth), вы можете настроить Grafana на использование адреса электронной почты в качестве уникального идентификатора пользователя. Для этого включите параметр oauth_allow_insecure_email_lookup, который по умолчанию отключён. Подробности см. в разделе Включение поиска по электронной почте.

Обратите внимание, что включение этого параметра может снизить безопасность вашего экземпляра Grafana. Если вы включаете этот параметр, убедитесь, что настройки Allowed organization, Allowed groups и Allowed domains заданы правильно, чтобы предотвратить несанкционированный доступ.

Многофакторная аутентификация (MFA/2FA)

Grafana и портал Grafana Cloud в настоящее время не включают встроенную поддержку многофакторной аутентификации (MFA).

Мы настоятельно рекомендуем интегрировать внешнего провайдера идентификации (IdP), который поддерживает MFA, такого как Okta, Entra ID или Google Workspace. Настроив ваши экземпляры Grafana на использование внешнего IdP, вы можете задействовать MFA для эффективной защиты своих учётных записей и ресурсов.

Вход и короткоживущие токены

Следующее применимо, если вы используете базовую аутентификацию Grafana, LDAP (без Auth proxy) или интеграцию OAuth.

Grafana использует короткоживущие токены для проверки аутентифицированных пользователей.

Вы можете настроить следующие параметры:

• token_rotation_interval_minutes: Задаёт интервал ротации токена для активных аутентифицированных пользователей.
• login_maximum_lifetime_duration: Задаёт, как долго пользователь остаётся аутентифицированным, прежде чем ему будет предложено аутентифицироваться снова.
• login_maximum_inactive_lifetime_duration: Задаёт, как долго неактивные аутентифицированные пользователи остаются в системе.
  • Пользователь может закрыть окно Grafana и вернуться до now + login_maximum_inactive_lifetime_duration, чтобы продолжить свою сессию.

Принудительный выход

При определённых обстоятельствах может потребоваться, чтобы ваши пользователи повторно аутентифицировались до того, как их сессия естественным образом истечёт. Хотя Grafana не предлагает отзыв сессий администратором как стандартную функциональность, у вас есть следующие обходные пути, если вам нужно принудительно завершить сессию пользователя:

• Удалите токен пользователя user_auth_token из базы данных. Это требует доступа к базе данных и недоступно клиентам Grafana Cloud.
• Установите login_maximum_lifetime_duration в 1 минуту, дождитесь вступления выхода в силу (обычно он выполняется менее чем за 10 минут), затем верните login_maximum_lifetime_duration к обычному значению.

Варианты использования включают:

• Миграции SSO: принудительная повторная аутентификация для получения новых IdP/разрешений
• Инциденты безопасности: немедленный ответ на компрометацию учётных данных
• Изменения разрешений: обеспечение немедленного вступления изменений ролей в силу
• Увольнение сотрудников: отзыв доступа без ожидания истечения сессии

Обработка сессий с SSO

При использовании методов аутентификации SSO (Single Sign-On) Grafana обрабатывает сессии по-разному в зависимости от конфигурации:

OAuth/OpenID Connect

• Без refresh-токенов (по умолчанию):
  • Grafana создаёт сессию, действительную до login_maximum_lifetime_duration (по умолчанию: 30 дней).
  • В течение этого времени сессия остаётся действительной, даже если пользователь теряет доступ в IdP.
• С включёнными refresh-токенами:
  • Пользователь получает refresh-токен JWT. Когда JWT истекает и refresh-токен используется для получения нового токена, Grafana повторно проверяет доступ с IdP.
  • Если пользователь был удалён из требуемых групп или доступ был отозван, обновление завершится неудачей и сессия будет аннулирована.

SAML

• После успешной аутентификации SAML Grafana создаёт сессию со сроком жизни сессии по умолчанию.
• Если SAML Single Logout (SLO) настроен правильно, сессия будет отозвана, когда доступ пользователя будет отозван на стороне IdP.
• Если SAML Single Logout (SLO) настроен правильно, сессия будет отозвана, когда доступ пользователя будет отозван на стороне IdP. Дополнительную информацию о настройке SAML и SLO см. в документации по конфигурации SAML.

Настройки

Пример:

Bash Copy

[auth]

# Login cookie name
login_cookie_name = grafana_session

# The maximum lifetime (duration) an authenticated user can be inactive before being required to login at next visit. Default is 7 days (7d). This setting should be expressed as a duration, e.g. 5m (minutes), 6h (hours), 10d (days), 2w (weeks), 1M (month). The lifetime resets at each successful token rotation (token_rotation_interval_minutes).
login_maximum_inactive_lifetime_duration =

# The maximum lifetime (duration) an authenticated user can be logged in since login time before being required to login. Default is 30 days (30d). This setting should be expressed as a duration, e.g. 5m (minutes), 6h (hours), 10d (days), 2w (weeks), 1M (month).
login_maximum_lifetime_duration =

# How often should auth tokens be rotated for authenticated users when being active. The default is every 10 minutes.
token_rotation_interval_minutes = 10

# The maximum lifetime (seconds) an API key can be used. If it is set all the API keys should have limited lifetime that is lower than this value.
api_key_max_seconds_to_live = -1

# Enforce user lookup based on email instead of the unique ID provided by the IdP.
oauth_allow_insecure_email_lookup = false

Расширенные настройки аутентификации

Включение поиска по электронной почте

По умолчанию Grafana идентифицирует пользователей на основе уникального ID, предоставленного провайдером идентификации (IdP). Однако в некоторых случаях включение поиска пользователей по электронной почте может быть приемлемым вариантом, например когда:

• Провайдер идентификации представляет собой однотенантную конфигурацию.
• Провайдер идентификации предоставляет уникальные, проверенные и неизменяемые адреса электронной почты.
• Инфраструктура позволяет выполнять идентификацию по электронной почте без ущерба для безопасности.

Важное замечание: Хотя можно настроить Grafana так, чтобы разрешить поиск пользователей по электронной почте, мы настоятельно не рекомендуем этот подход в большинстве случаев из-за потенциальных рисков безопасности. Если вы всё же решите продолжить, для включения поиска по электронной почте можно применить следующую конфигурацию.

Bash Copy

[auth]
oauth_allow_insecure_email_lookup = true

Вы также можете включить поиск по электронной почте с помощью API:

Copy

curl --request PUT \
  --url http://{slug}.grafana.com/api/admin/settings \
  --header 'Authorization: Bearer glsa_yourserviceaccounttoken' \
  --header 'Content-Type: application/json' \
  --data '{ "updates": { "auth": { "oauth_allow_insecure_email_lookup": "true" }}}'

Наконец, вы также можете включить его через пользовательский интерфейс, перейдя в Administration -> Authentication -> Auth settings.

Автоматический вход OAuth

Установите значение true, чтобы пытаться автоматически войти с конкретным провайдером OAuth, пропуская экран входа. Этот параметр игнорируется, если несколько провайдеров аутентификации настроены на использование автоматического входа. Значение по умолчанию — false.

Bash Copy

[auth.generic_oauth]
auto_login = true

Отключение автоматического входа

Параметр URL disableAutoLogin=true позволяет пользователям обойти функцию автоматического входа в сценариях, когда неправильные изменения конфигурации препятствуют нормальному функционированию входа. Эта функция особенно полезна, когда вам нужно получить доступ к экрану входа, чтобы устранить неполадки и исправить ошибки конфигурации.

Как использовать

1. Добавьте disableAutoLogin=true как параметр запроса к вашему URL Grafana.
   • Пример: grafana.example.net/login?disableAutoLogin=true или grafana.example.net/login?disableAutoLogin
2. Это перенаправит вас на стандартный экран входа, обходя механизм автоматического входа.
3. Исправьте любые проблемы конфигурации и проверьте настройку входа.

Эта функция доступна как для OAuth, так и для SAML. Убедитесь, что после исправления проблемы вы удалили параметр или вернули конфигурацию, чтобы снова включить функцию автоматического входа, если это необходимо.

Скрытие меню выхода

Установите описанный ниже параметр в true, чтобы скрыть ссылку меню выхода. Полезно, если вы используете auth proxy или аутентификацию JWT.

Bash Copy

[auth]
disable_signout_menu = true

Перенаправление по URL после выхода

URL для перенаправления пользователя после выхода из Grafana. Это можно, например, использовать для включения выхода из провайдера OAuth.

Пример для Generic OAuth:

Bash Copy

[auth.generic_oauth]
signout_redirect_url =

Удалённый выход

Вы можете выйти на других устройствах, удалив сессии входа в нижней части страницы своего профиля. Если вы администратор Grafana, вы также можете сделать то же самое для любого пользователя из представления Server Admin / Edit User.

Защищённые роли

По умолчанию после настройки провайдера авторизации Grafana примет существующих пользователей в новую схему аутентификации. Например, если вы создали пользователя с базовой аутентификацией с логином jsmith@example.com, а затем настроили аутентификацию SAML, где jsmith@example.com является учётной записью, тип аутентификации пользователя будет изменён на SAML, если он выполнит вход через SAML.

Вы можете отключить это принятие пользователей для определённых ролей с помощью свойства protected_roles:

Bash Copy

[auth.security]
protected_roles = server_admins org_admins

Значение protected_roles должно быть списком ролей для защиты, разделённых пробелами. Допустимые роли: viewers, editors, org_admins, server_admins и all (надмножество остальных ролей).