Защита Grafana и Prometheus двухфакторной аутентификацией: практическая настройка для DevOps | AdminWiki
Timeweb Cloud — сервера, Kubernetes, S3, Terraform. Лучшие цены IaaS.
Попробовать

Защита Grafana и Prometheus двухфакторной аутентификацией: практическая настройка для DevOps

19 мая 2026 10 мин. чтения
Содержание статьи

Зачем DevOps нужна двухфакторная аутентификация для Grafana и Prometheus

Интерфейсы Grafana и API Prometheus содержат критически важные данные о состоянии инфраструктуры: метрики производительности, логи, конфигурации дашбордов и информации о состоянии сервисов. Компрометация доступа к этим системам позволяет злоумышленнику не только узнать конфиденциальные сведения о внутренней архитектуре, но и скрыть следы инцидента, манипулируя данными мониторинга. Парольной защиты недостаточно, особенно при использовании стандартных или слабых учетных данных. Двухфакторная аутентификация (2FA) создает дополнительный барьер, который блокирует 99.9% автоматизированных атак на учетные записи. Для DevOps инженера внедрение 2FA для систем мониторинга это не опция, а обязательный элемент базовой гигиены безопасности production-среды.

Обзор подходов: OAuth2 провайдеры vs. Единый шлюз аутентификации

Существует два основных практических метода внедрения 2FA для стека мониторинга. Выбор зависит от масштаба инфраструктуры, доступных ресурсов и требований к безопасности.

Когда выбирать OAuth2 провайдер (Google, GitHub)

Этот метод оптимален для небольших команд или стартапов, которые уже используют Google Workspace или GitHub Organizations. Он позволяет быстро защитить Grafana, делегировав управление аутентификацией и 2FA внешнему, надежному провайдеру. Вам не нужно развертывать и поддерживать отдельный сервис аутентификации. Метод подходит, если основная задача закрыть доступ к Grafana, а Prometheus и другие инструменты защищены иным способом (например, доступны только из внутренней сети).

Когда выбирать шлюз аутентификации (Authelia)

Authelia или аналогичные решения (например, Keycloak за обратным прокси) подходят для корпоративных сред, требующих единой политики доступа ко всем внутренним веб-интерфейсам. Этот метод позволяет защитить не только Grafana, но и веб-интерфейс Prometheus, Alertmanager, а также любые другие внутренние панели управления. Решение независимо от внешних SaaS-сервисов и предоставляет полный контроль над политиками аутентификации, включая двухфакторную. Он требует больше усилий для первоначальной настройки и поддержки.

Критерий OAuth2 провайдер (Google/GitHub) Шлюз аутентификации (Authelia)
Защита Grafana Да Да
Защита Prometheus Web UI Нет (требует отдельного прокси) Да
Зависимость от внешнего сервиса Высокая Отсутствует
Сложность внедрения Низкая Средняя/Высокая
Управление пользователями У провайдера (Google/GitHub) Локально (файл, LDAP)
Идеальный сценарий Малые команды, быстрый старт Корпоративная среда, единая политика

Метод 1: Настройка 2FA в Grafana через OAuth2 провайдер (Google/GitHub)

Это пошаговое руководство для быстрого внедрения 2FA в Grafana версии 10.x и новее.

Готовая конфигурация grafana.ini для Google OAuth2

После создания OAuth2 клиента в Google Cloud Console (тип "Веб-приложение") с URI перенаправления https://your-grafana-domain.com/login/google, добавьте в grafana.ini следующую секцию. Убедитесь, что ваш Grafana работает по HTTPS.

[auth.google]
enabled = true
client_id = YOUR_CLIENT_ID.apps.googleusercontent.com
client_secret = YOUR_CLIENT_SECRET
scopes = openid email profile
allowed_domains = your-company.com
allow_sign_up = false
auth_url = https://accounts.google.com/o/oauth2/auth
token_url = https://oauth2.googleapis.com/token
api_url = https://www.googleapis.com/oauth2/v1/userinfo

client_id и client_secret берутся из консоли Google. allowed_domains ограничивает вход пользователям с определенных доменов почты. allow_sign_up = false запрещает автоматическое создание новых пользователей в Grafana; их нужно предварительно добавить вручную через интерфейс администрирования.

Готовая конфигурация grafana.ini для GitHub OAuth2

Для использования GitHub OAuth2 создайте OAuth App в настройках GitHub (Settings -> Developer settings). Redirect URI: https://your-grafana-domain.com/login/github.

[auth.github]
enabled = true
client_id = YOUR_GITHUB_CLIENT_ID
client_secret = YOUR_GITHUB_CLIENT_SECRET
scopes = user:email,read:org
auth_url = https://github.com/login/oauth/authorize
token_url = https://github.com/login/oauth/access_token
api_url = https://api.github.com/user
allowed_organizations = your-github-org-name
role_attribute_path = isAdmin && 'Admin' || 'Viewer'
allow_sign_up = false

allowed_organizations ограничивает доступ членам конкретной GitHub-организации. role_attribute_path это пример выражения для назначения роли в Grafana на основе данных из GitHub API (требует дополнительной настройки).

Тестирование и первичный вход

  1. Перезапустите службу Grafana: systemctl restart grafana-server или перезапустите контейнер.
  2. Откройте страницу входа в Grafana. Должна появиться новая кнопка "Войти через Google" или "Войти через GitHub".
  3. Нажмите на кнопку. Вы будете перенаправлены на страницу провайдера (Google/GitHub).
  4. Если у вашего аккаунта провайдера включена 2FA (TOTP, SMS), вам будет предложено ввести второй фактор.
  5. После успешной аутентификации вы вернетесь в Grafana. Проверьте, создан ли пользователь с правильным email и назначена ли ему роль.

Если кнопка не появилась, проверьте логи Grafana (journalctl -u grafana-server -f) на наличие ошибок в конфигурации OAuth.

Метод 2: Защита Grafana и Prometheus через шлюз Authelia

Этот метод создает единый защищенный вход для всех веб-интерфейсов.

Docker Compose для развертывания Authelia

Создайте docker-compose.yml для запуска Authelia и обратного прокси (Nginx).

version: '3.8'

services:
  authelia:
    image: authelia/authelia:latest
    container_name: authelia
    volumes:
      - ./authelia/config:/config
    environment:
      - TZ=Europe/Moscow
    networks:
      - proxy-network

  nginx:
    image: nginx:alpine
    container_name: nginx-proxy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx/conf.d:/etc/nginx/conf.d:ro
      - ./nginx/ssl:/etc/nginx/ssl:ro
    depends_on:
      - authelia
    networks:
      - proxy-network

networks:
  proxy-network:
    driver: bridge

Ключевые секции configuration.yml Authelia

В файле ./authelia/config/configuration.yml настройте основные параметры.

default_redirection_url: https://grafana.your-domain.com

server:
  host: 0.0.0.0
  port: 9091

session:
  name: authelia_session
  secret: YOUR_VERY_LONG_RANDOM_SECRET_KEY_HERE # Сгенерируйте через openssl rand -hex 64
  domain: your-domain.com

authentication_backend:
  file:
    path: /config/users_database.yml
    password:
      algorithm: argon2id

access_control:
  default_policy: deny
  rules:
    - domain: "grafana.your-domain.com"
      policy: two_factor
    - domain: "prometheus.your-domain.com"
      policy: two_factor
    - domain: "alertmanager.your-domain.com"
      policy: two_factor

Файл users_database.yml содержит хэши паролей пользователей. Для генерации хэша используйте команду docker run --rm authelia/authelia:latest authelia crypto hash generate --password 'yourpassword'.

Конфигурация Nginx как reverse proxy с интеграцией Authelia

Настройте Nginx (./nginx/conf.d/default.conf) для проксирования запросов через Authelia.

# Общая настройка для проверки аутентификации через Authelia
location /authelia {
    internal;
    proxy_pass http://authelia:9091/api/verify;
    proxy_pass_request_body off;
    proxy_set_header Content-Length "";
    proxy_set_header X-Original-URL $scheme://$http_host$request_uri;
}

# Локация для Grafana
location /grafana/ {
    set $upstream grafana:3000;
    auth_request /authelia;
    auth_request_set $user $upstream_http_remote_user;
    auth_request_set $email $upstream_http_remote_email;
    auth_request_set $groups $upstream_http_remote_groups;

    proxy_set_header X-WEBAUTH-USER $user;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_pass http://$upserver;
}

# Локация для Prometheus
location /prometheus/ {
    set $upstream prometheus:9090;
    auth_request /authelia;
    error_page 401 =302 https://auth.your-domain.com/?rd=$scheme://$http_host$request_uri;
    proxy_pass http://$upstream;
}

Настройка Grafana для работы с аутентификацией от прокси (auth.proxy)

Чтобы Grafana принимала аутентификацию от Nginx/Authelia, отредактируйте grafana.ini.

[auth.proxy]
enabled = true
header_name = X-WEBAUTH-USER
header_property = username
auto_sign_up = true
whitelist = 172.16.0.0/12  # Укажите подсеть, из которой идет трафик с прокси

[auth.basic]
enabled = false  # Отключаем стандартную форму входа

После этой настройки Grafana будет создавать пользователей на основе заголовка X-WEBAUTH-USER, который передает Nginx после успешной проверки в Authelia.

Критически важный этап: тестирование полного цикла и создание резервных кодов

Перед переводом системы в production необходимо провести полное тестирование и создать механизмы восстановления на случай потери доступа.

Чек-лист тестирования аутентификации

  1. Доступ без аутентификации: Попробуйте открыть https://grafana.your-domain.com в режиме инкогнито. Должна произойти переадресация на страницу входа Authelia или OAuth2 провайдера.
  2. Успешный вход с 2FA: Пройдите полный цикл: ввод логина/пароля, затем ввод TOTP-кода из приложения-аутентификатора. Вы должны оказаться в интерфейсе Grafana.
  3. Проверка сессии: Закройте браузер и снова откройте Grafana. В зависимости от настроек сессии Authelia, вас могут попросить ввести пароль снова или оставить авторизованным.
  4. Проверка доступа к Prometheus: Перейдите по адресу https://prometheus.your-domain.com. Должна сработать та же проверка Authelia.
  5. Выход: Найдите и используйте кнопку выхода в интерфейсе Authelia или Grafana. После выхода доступ должен быть заблокирован.

Резервные коды: ваша страховка от потери доступа

Резервные коды это одноразовые пароли, которые заменяют второй фактор аутентификации (TOTP) в случае потери телефона или сбоя приложения-аутентификатора. Каждый код можно использовать только один раз. Их наличие критически важно для восстановления доступа администратора.

  • Для метода с OAuth2 (Google/GitHub): Резервные коды управляются на стороне провайдера. В аккаунте Google перейдите в "Безопасность" -> "Двухэтапная аутентификация" -> "Резервные коды". В GitHub: "Settings" -> "Password and authentication" -> "Two-factor authentication" -> "Recovery codes". Скачайте или скопируйте эти 10-16 кодов.
  • Для метода с Authelia: При включении 2FA для пользователя в веб-интерфейсе Authelia отображаются резервные коды. Их также можно сгенерировать через CLI.

Рекомендации по хранению (на основе практик безопасности):

  1. Храните копии резервных кодов минимум в 2-3 физически разделенных и безопасных местах. Например: сейф в офисе, зашифрованный USB-накопитель дома, бумажная копия в банковской ячейке.
  2. Никогда не храните единственную копию кодов на том же сервере, который они защищают, или в том же менеджере паролей, что и основной пароль. Это создает единую точку отказа.
  3. Не отправляйте коды по email или в мессенджеры.

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

Типичные проблемы при внедрении и их решение

Вот список распространенных ошибок и способы их устранения.

Проблемы с конфигурацией OAuth2 и Grafana

  • Ошибка "Invalid OAuth2 state": Чаще всего возникает из-за несовпадения домена в браузере и в настройках OAuth2 клиента. Убедитесь, что redirect_uri в консоли провайдера и адрес вашего Grafana совпадают до символа, включая HTTP/HTTPS. Также проверьте, что системное время на сервере Grafana синхронизировано (используйте NTP).
  • Ошибка "User not found in allowed domains": Проверьте параметр allowed_domains в grafana.ini. Убедитесь, что email пользователя, который пытается войти, принадлежит одному из указанных доменов.
  • Пользователь не создается в Grafana: Если allow_sign_up = false, пользователь должен быть предварительно добавлен в Grafana через панель администрирования. Если auto_sign_up = true (для auth.proxy), проверьте передаваемый заголовок.

Проблемы с интеграцией Authelia и обратного прокси

  • Nginx возвращает 502 Bad Gateway после входа в Authelia: Проверьте, что upstream-сервисы (Grafana, Prometheus) доступны из сети контейнера Nginx. Убедитесь в правильности имени хоста и порта в директиве proxy_pass.
  • Grafana показывает "Invalid username or password" после успешного входа через прокси: Grafana не получает или не распознает заголовок аутентификации. Проверьте:
    1) В конфиге Nginx: правильно ли задано proxy_set_header X-WEBAUTH-USER $user;.
    2) В конфиге Grafana: совпадает ли header_name в [auth.proxy] с заголовком из Nginx (по умолчанию X-WEBAUTH-USER).
    3) Не блокирует ли Grafana IP-адрес прокси. Проверьте whitelist в grafana.ini.
  • Prometheus возвращает 401 на запросы от Alertmanager или других сервисов: Эти запросы не проходят через браузер и не могут аутентифицироваться через веб-форму. Создайте в конфигурации Nginx отдельное правило location для API Prometheus (/api/v1/), которое будет пропускать запросы с определенных доверенных IP-адресов без проверки Authelia, используя директиву satisfy any и allow.
  • Бесконечный редирект между Grafana и Authelia: Одна из самых частых проблем. Проверьте:
    1) В Authelia: default_redirection_url должен вести на защищенный ресурс (например, Grafana), а не на себя.
    2) В Nginx: В директиве error_page 401 убедитесь, что rd (redirect) параметр указывает на текущий запрошенный URL.
    3) Куки: Убедитесь, что домен в настройках сессии Authelia (session.domain) является родительским для всех защищаемых поддоменов (например, your-domain.com), и что все сервисы работают по HTTPS с корректными сертификатами.

Если вы столкнулись с проблемами на уровне сети или подозреваете сложную атаку, ознакомьтесь с практическим сравнением методов защиты от DDoS-атак, которое включает настройку правил на уровне приложения (L7).

Дальнейшие шаги: автоматизация и интеграция с корпоративной инфраструктурой

После успешного внедрения базовой настройки можно перейти к ее оптимизации и интеграции.

  1. Автоматизация развертывания: Конфигурации Docker Compose, Nginx и Authelia можно упаковать в Ansible-роль или Terraform-модуль. Это позволит воспроизводить настройку в разных окружениях (stage, production) и управлять ею как кодом. Например, секреты (client_secret, session.secret) следует выносить в переменные окружения или специализированные хранилища (HashiCorp Vault).
  2. Интеграция с корпоративной аутентификацией: Authelia поддерживает несколько бэкендов. Вместо файла users_database.yml можно настроить подключение к LDAP или Active Directory. Это централизует управление пользователями. Для Grafana с OAuth2 можно использовать корпоративные SAML или OIDC провайдеры, такие как Okta, Keycloak или Azure AD, которые уже имеют встроенную поддержку 2FA.
  3. Расширение защиты: Шаблон с обратным прокси и Authelia можно применить для защиты любых других внутренних веб-интерфейсов: pgAdmin для PostgreSQL, интерфейсы управления очередями (RabbitMQ), системы трассировки (Jaeger). Это создает единую точку входа и соблюдения политик безопасности для всей внутренней инфраструктуры.
  4. Мониторинг и аудит: Настройте сбор логов аутентификации из Authelia в центральную систему (например, Loki или Elasticsearch). Отслеживайте неудачные попытки входа, которые могут указывать на попытки подбора.

Для управления доступом к другим ключевым инфраструктурным инструментам, таким как Portainer или GitLab, вы можете адаптировать подходы из этого руководства или воспользоваться специализированными инструкциями по настройке 2FA для Portainer, Grafana и GitLab.

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

Поделиться:
Сохранить гайд? В закладки браузера