Авторизация

Значения по умоланию

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

Если значения не указать - будут использованы значения по умолчанию:

Пользователь: admin-internal

Проль: admin

Identity Provider

IDP (Identity Provider, поставщик удостоверений) — встроенный сервис аутентификации платформы Астра Мониторинг. Сервис работает по протоколу OpenID Connect (стандарт аутентификации на базе OAuth 2.0) и позволяет пользователям входить в платформу с помощью учётных записей из корпоративного каталога LDAP (Lightweight Directory Access Protocol) или через внешнего провайдера OIDC (OpenID Connect).

IDP не хранит пароли пользователей — аутентификация всегда делегируется внешним системам (LDAP или OIDC). После успешной проверки учётных данных IDP выдаёт JWT-токен (JSON Web Token), который используется для доступа к платформе.

Поток входа

Пользователь → IDP AM → LDAP/OIDC → JWT-токен → Платформа Астра Мониторинг

Ключевые адреса

Адрес	Назначение
`https://<адрес-сервера>/oidc/realms/astra-monitoring`	Публичный адрес сервиса IDP
`https://<адрес-сервера>/oidc/realms/astra-monitoring/.well-known/openid-configuration`	Автоматическая конфигурация для клиентов (Discovery)
`https://<адрес-сервера>/oidc/realms/astra-monitoring/keys`	Публичные ключи для проверки токенов (JWKS)

Примечание

IDP AM внутри использует движок Dex — поэтому в конфигурационных файлах ключи начинаются с dex.*. Снаружи сервис доступен по пути /oidc/realms/astra-monitoring через nginx-прокси (docker-compose) или Ingress (kubernetes). Пользователи и клиенты обращаются только к публичному адресу — все запросы проксируются до контейнера identity-provider.

Для пользователей — Вход в систему

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

Методы авторизации

LDAP (имя пользователя)

Выберите LDAP (username) и введите:

Username — ваше имя пользователя (логин в корпоративном каталоге)
Пароль — пароль от корпоративной учётной записи

LDAP (email)

Выберите LDAP (email) и введите:

Email — ваш адрес электронной почты
Пароль — пароль от корпоративной учётной записи

OIDC (единый вход)

Выберите внешнего провайдера (например, Keycloak SSO). Вы будете перенаправлены на страницу входа провайдера. После успешной аутентификации — автоматически возвращены в платформу.

Статический пользователь

Введите логин и пароль локального пользователя, заданного администратором в конфигурации IDP.

Предупреждение

Этот метод предназначен только для первичного входа и настройки системы. После настройки коннекторов LDAP/OIDC статический пользователь должен быть удалён.

Единый вход (SSO)

При активной сессии IDP повторный вход в другое приложение происходит без повторного ввода пароля.

Роли

В платформе есть три системные роли:

Администратор — полный доступ ко всему функционалу
Сотрудник — полный доступ, за исключением раздела «Администрирование»
Наблюдатель — доступ на просмотр, за исключением раздела «Администрирование»

Роль определяется группой из LDAP или OIDC, в которой состоит пользователь. Подробнее — Пользователи.

Для администраторов — Настройка

Установка и запуск

docker-compose

Добавьте аргумент --profile idp к команде запуска:

Запуск с IDP вместо Keycloak

./start.sh <server-ip> --profile idp

При запуске с этим аргументом используется профиль IDP вместо Keycloak. Keycloak не запускается — nginx автоматически направляет запросы /oidc/* на контейнер identity-provider. Конфигурация подключений находится в файле identity-provider/bootstrap.yaml внутри директории развёртывания.

kubernetes

Для отключения Keycloak и включения IDP используйте опцию keycloak.enable="false":

Установка через Helm

helm upgrade astra-monitoring am-helm/astra-icl-monitoring \
  -n astra-monitoring \
  --install \
  --set keycloak.enable="false"

Конфигурация IDP настраивается через блок identity_provider в файле values.yaml Helm-чарта.

Конфигурация IDP

Конфигурация задаётся в YAML-файле и через переменные окружения. Переменные окружения имеют приоритет над файлом.

Docker-compose — файл identity-provider/bootstrap.yaml в директории развёртывания
Kubernetes — блок identity_provider в values.yaml Helm-чарта

Структура конфигурации

Параметры развёртывания (identity_provider.*):

Параметр	Описание
`image`	Образ контейнера IDP
`tag`	Версия образа
`port`	Порт сервиса (по умолчанию 8080)
`log_level`	Уровень логирования
`static_passwords`	Статические пользователи (см. раздел «Статический пользователь»)
`connectors`	Коннекторы аутентификации (LDAP, OIDC)

Параметры сервиса (внутренняя конфигурация IDP):

Блок	Описание
`dex.issuer`	Публичный URL сервиса IDP
`dex.web_path`	Базовый путь (по умолчанию `/oidc/realms/astra-monitoring`)
`dex.storage_config`	Настройки подключения к PostgreSQL
`dex.static_clients`	OAuth2-клиенты платформы
`dex.connectors`	Коннекторы аутентификации (LDAP, OIDC)

Конфигурация для первичного входа

При первом запуске системы необходимо настроить статического пользователя-администратора для выполнения первичной настройки. Блок static_passwords создаёт локального пользователя, через которого можно войти в платформу до подключения внешних источников аутентификации (LDAP/OIDC).

bootstrap.yaml — первичная настройка (для первого входа)

http:
  listen: ":8080"
  tls_enabled: false
  shutdown_timeout: "10s"

dex:
  issuer: "https://<адрес-сервера>/oidc/realms/astra-monitoring"
  web_path: "/oidc/realms/astra-monitoring"
  enable_password_db: true
  storage_type: "postgres"
  storage_config:
    postgres_dsn: ""             # задать через ENV
    migrate: true
  static_clients:
    - id: "admin-ui"
      secret: ""                 # задать через ENV
      redirect_uris:
        - "https://<адрес-сервера>"
        - "https://<адрес-сервера>/"

  # Статический пользователь для первичной настройки
  static_passwords:
    - email: "admin-internal"
      username: "admin-internal"
      hash: ""                   # bcrypt-хеш пароля (см. ниже)
      groups:
        - "Administrators"

static_passwords — блок, необходимый для первичного входа в систему:
- username — имя пользователя для входа
- hash — bcrypt-хеш пароля (генерация: htpasswd -bnBC 12 "" <пароль> | tr -d ':\n')
- groups — группа Administrators даёт полный доступ для первичной настройки
enable_password_db: true — обязательно для работы статических паролей

Важно

После первичной настройки добавьте в конфигурацию блок connectors с подключениями к LDAP/OIDC (см. раздел «Подключение коннекторов»), удалите блок static_passwords и перезапустите сервер.

Конфигурация для рабочего режима

После первичной настройки конфигурация переводится в рабочий режим — вместо static_passwords указываются коннекторы:

bootstrap.yaml — рабочий режим (LDAP/OIDC)

http:
  listen: ":8080"
  tls_enabled: false
  shutdown_timeout: "10s"

dex:
  issuer: "https://<адрес-сервера>/oidc/realms/astra-monitoring"
  web_path: "/oidc/realms/astra-monitoring"
  enable_password_db: false      # статические пароли отключены
  storage_type: "postgres"
  storage_config:
    postgres_dsn: ""             # задать через ENV
    migrate: true
  static_clients:
    - id: "admin-ui"
      secret: ""                 # задать через ENV
      redirect_uris:
        - "https://<адрес-сервера>"
        - "https://<адрес-сервера>/"
  connectors:
    - type: ldap
      id: "ldap-uid"
      name: "LDAP (логин uid)"
      config:
        host: "ldaps://ldap.example.com:636"
        startTLS: false
        insecureNoSSL: false
        bindDN: ""               # через ENV
        bindPW: ""               # через ENV
        userSearch:
          baseDN: "cn=users,dc=example,dc=loc"
          filter: "(|(objectClass=inetOrgPerson)(objectClass=person))"
          username: "uid"
          idAttr: "uid"
          emailAttr: "mail"
          nameAttr: "cn"
        groupSearch:
          baseDN: "cn=groups,dc=example,dc=loc"
          filter: "(objectClass=groupOfNames)"
          userMatchers:
            - userAttr: "DN"
              groupAttr: "member"
          nameAttr: "cn"

Переопределение через переменные окружения

Переменные с префиксом APP_ перекрывают значения из файла. Уровни разделяются __, индексы массивов — __{index}__.

Переменная	Соответствующий ключ	Описание
`APP_dex__storage_config__postgres_dsn`	`dex.storage_config.postgres_dsn`	Строка подключения PostgreSQL
`APP_dex__static_clients__0__secret`	`dex.static_clients[0].secret`	Секрет клиента
`APP_dex__connectors__0__config__bindDN`	`dex.connectors[0].config.bindDN`	LDAP bind DN
`APP_dex__connectors__0__config__bindPW`	`dex.connectors[0].config.bindPW`	LDAP bind пароль

Пример переменных окружения

APP_dex__storage_config__postgres_dsn=postgres://user:pass@host:5432/db?sslmode=require
APP_dex__static_clients__0__secret=...
APP_dex__connectors__0__config__bindDN=uid=idp-am,cn=users,dc=example,dc=loc
APP_dex__connectors__0__config__bindPW=********

Важно

Секреты (пароли, ключи, строки подключения) задаются только через переменные окружения. Не храните секреты в YAML-файлах.

Подключение коннекторов

LDAP (username)

Коннектор LDAP (username)

identity_provider:
  connectors:
    - type: ldap
      id: ldap-username
      name: "LDAP (username)"
      config:
        usernamePrompt: "Username"
        host: "ldaps://ldap.example.com:636"
        insecureNoSSL: false
        startTLS: false
        bindDN: "uid=mon_viewer,cn=users,cn=accounts,dc=example,dc=loc"
        bindPW: ""               # через ENV
        userSearch:
          baseDN: "cn=users,cn=accounts,dc=example,dc=loc"
          filter: "(|(objectClass=ipaUser)(objectClass=person))"
          username: "uid"
          idAttr: "uid"
          emailAttr: "mail"
          nameAttr: "cn"
        groupSearch:
          baseDN: "cn=groups,cn=accounts,dc=example,dc=loc"
          filter: "(objectClass=groupOfNames)"
          userMatchers:
            - userAttr: "DN"
              groupAttr: "member"
          nameAttr: "cn"

Параметры подключения:

Параметр	Описание
`host`	Адрес LDAP-сервера: `ldaps://host:636` или `ldap://host:389`
`insecureNoSSL`	Отключить SSL (только для dev)
`startTLS`	Использовать StartTLS при `ldap://`
`bindDN`	DN (Distinguished Name) пользователя для подключения к LDAP
`bindPW`	Пароль для подключения к LDAP

Поиск пользователей (userSearch):

Поле	Пример	Описание
`baseDN`	`cn=users,dc=example,dc=loc`	База поиска пользователей
`filter`	`(objectClass=inetOrgPerson)`	LDAP-фильтр
`username`	`uid`	Поле логина
`idAttr`	`uid`	Уникальный идентификатор
`emailAttr`	`mail`	Email
`nameAttr`	`cn`	Отображаемое имя

Поиск групп (groupSearch):

Поле	Пример	Описание
`baseDN`	`cn=groups,dc=example,dc=loc`	База поиска групп
`filter`	`(objectClass=groupOfNames)`	LDAP-фильтр
`userMatchers[].userAttr`	`DN`	Атрибут пользователя для сопоставления
`userMatchers[].groupAttr`	`member`	Атрибут группы для членов
`nameAttr`	`cn`	Имя группы (определяет роль в платформе)

LDAP (email)

Аналогично LDAP (username), но для входа по email:

Коннектор LDAP (email) — отличия от username

identity_provider:
  connectors:
    - type: ldap
      id: ldap-email
      name: "LDAP (email)"
      config:
        usernamePrompt: "Email"
        host: "ldaps://ldap.example.com:636"
        insecureNoSSL: false
        startTLS: false
        bindDN: "uid=mon_viewer,cn=users,cn=accounts,dc=example,dc=loc"
        bindPW: ""               # через ENV
        userSearch:
          baseDN: "cn=users,cn=accounts,dc=example,dc=loc"
          filter: "(|(objectClass=ipaUser)(objectClass=person))"
          username: "mail"       # отличие: используется mail вместо uid
          idAttr: "uid"
          emailAttr: "mail"
          nameAttr: "cn"
        groupSearch:
          baseDN: "cn=groups,cn=accounts,dc=example,dc=loc"
          filter: "(objectClass=groupOfNames)"
          userMatchers:
            - userAttr: "DN"
              groupAttr: "member"
          nameAttr: "cn"

Ключевое отличие: username: "mail" — для входа используется email вместо логина.

OIDC (Keycloak SSO)

Коннектор OIDC (Keycloak)

identity_provider:
  connectors:
    - type: oidc
      id: keycloak
      name: "Keycloak SSO"
      config:
        issuer: "https://keycloak.example.com/realms/astra-monitoring"
        clientID: "dex_client"
        clientSecret: ""         # через ENV
        redirectURI: "https://am.example.com/oidc/realms/astra-monitoring/callback"
        scopes:
          - openid
          - profile
          - groups
        claimMapping:
          userIDKey: "sub"
          userNameKey: "preferred_username"
          emailKey: "email"
          groupsKey: "groups"
        insecureSkipVerify: false
        insecureEnableGroups: true
        insecureSkipEmailVerified: true
        insecureSkipIssuerVerification: false
        getUserInfo: false

Параметры подключения:

Параметр	Описание
`issuer`	URL realm Keycloak
`clientID`	ID клиента, созданного в Keycloak
`clientSecret`	Секрет клиента
`redirectURI`	URL возврата после авторизации (абсолютный, должен содержать `web_path`)
`scopes`	Запрашиваемые разрешения: `openid`, `profile`, `groups`

Маппинг полей (claimMapping):

Поле	Значение	Описание
`userIDKey`	`sub`	Уникальный идентификатор пользователя
`userNameKey`	`preferred_username`	Логин пользователя
`emailKey`	`email`	Email пользователя
`groupsKey`	`groups`	Поле с группами

Флаги безопасности:

Флаг	Описание	Prod
`insecureSkipVerify`	Отключить проверку TLS-сертификата	`false`
`insecureEnableGroups`	Включить передачу групп	по необходимости
`insecureSkipEmailVerified`	Не требовать подтверждения email	`false`
`insecureSkipIssuerVerification`	Не проверять издателя токена	`false`
`getUserInfo`	Получать доп. атрибуты через userinfo endpoint	`false`

Важно

В production все insecure* флаги должны быть false.

Статический пользователь (нулевой администратор)

Статический пользователь задаётся в конфигурации IDP и предназначен для первичного входа и настройки системы.

Предупреждение

После настройки коннекторов LDAP/OIDC статический пользователь должен быть удалён. Его наличие в production-конфигурации является уязвимостью.

Пример static_passwords

identity_provider:
  static_passwords:
    - email: "admin-internal"
      username: "admin-internal"
      hash: "$2y$12$To9g2G0pbTfdsPanGWwBo.6RLY4Tst7.xPf3q/X78ApwtPL8fKCA2"
      groups:
        - "Administrators"

email/username — логин статического пользователя
hash — bcrypt-хеш пароля. Для генерации:

Генерация bcrypt-хеша

htpasswd -bnBC 12 "" <пароль> | tr -d ':\n'

groups — группа, определяющая роль пользователя в платформе

Пошаговый сценарий настройки

Этап 1 — Первичный вход:

Подготовьте bootstrap.yaml по шаблону «Конфигурация для первичного входа» (см. выше). Сгенерируйте bcrypt-хеш пароля для admin-internal:
```
htpasswd -bnBC 12 "" <пароль> | tr -d ':\n'
```
Установите АМ с профилем IDP (docker-compose: --profile idp, kubernetes: keycloak.enable="false")
Войдите в платформу под admin-internal с заданным паролем
Убедитесь, что интерфейс доступен и работает корректно

Этап 2 — Подключение внешней аутентификации:

Добавьте в bootstrap.yaml блок connectors с подключениями к LDAP и/или OIDC (см. раздел «Подключение коннекторов»)
Перезапустите сервер
Убедитесь, что внешние пользователи могут входить в систему с нужными ролями

Примечание

Группы из LDAP/OIDC маппятся в роли AM автоматически. Убедитесь, что в LDAP пользователи состоят в соответствующих группах (Administrators, Employees, Observers).

Этап 3 — Удаление статического пользователя:

Убедитесь, что внешний пользователь с ролью администратора может успешно войти в систему

Предупреждение

Перед удалением нулевого администратора обязательно проверьте, что вход через LDAP/OIDC работает и у внешнего пользователя есть роль администратора.

Удалите блок static_passwords из bootstrap.yaml и установите enable_password_db: false
Перезапустите сервер
Система настроена — дальнейшая работа происходит под внешними пользователями

Управление ролями и маппинг групп

Роль пользователя определяется группой из LDAP/OIDC:

Группа	Роль в AM
`Administrators`	Администратор — полный доступ
`Employees`	Сотрудник — без раздела «Администрирование»
`Observers`	Наблюдатель — только просмотр

Группы назначаются:

LDAP/OIDC пользователи — группы приходят из каталога (LDAP groupSearch или OIDC groupsKey)
Статические пользователи — группы задаются в static_passwords[].groups

Подробнее о ролях — Пользователи.

Миграция с Keycloak

Когда нужна миграция

При обновлении Астра Мониторинг с версии, использующей Keycloak, на версию с IDP AM.

Ключевые отличия

Keycloak	IDP AM
Web-консоль администрирования	Конфигурация через YAML-файл
Концепция realm (области)	Единый issuer (путь `/oidc/realms/astra-monitoring` сохранён для совместимости)
Встроенное хранилище пользователей	LDAP/OIDC (локальные — только статические)
Поддержка множества протоколов	Только OIDC
Управление сессиями через UI	Настройка через конфигурацию

Переходный вариант: OIDC-коннектор к Keycloak

Для плавной миграции можно настроить IDP AM на делегирование аутентификации существующему Keycloak:

Разверните АМ с профилем IDP
Настройте OIDC-коннектор, указывающий на Keycloak
Убедитесь, что пользователи могут аутентифицироваться через Keycloak → IDP AM → AM
Переключитесь на прямые LDAP-коннекторы
Декомиссируйте Keycloak

Шаги миграции

Установите новую версию АМ с профилем IDP (вместо Keycloak)
Перенесите настройки подключения к LDAP из конфигурации Keycloak в конфигурацию IDP AM
Проверьте маппинг групп: группы LDAP должны совпадать с ролями AM (Administrators, Employees, Observers)
Убедитесь, что пользователи могут войти через IDP AM
Декомиссируйте Keycloak

Эксплуатация (SRE)

Проверки доступности

Проверка	Как	Ожидаемое
Readiness	`GET https://<адрес-сервера>/oidc/realms/astra-monitoring/.well-known/openid-configuration`	`200 OK`
JWKs	`GET https://<адрес-сервера>/oidc/realms/astra-monitoring/keys`	`200 OK`, ключи с `kid`
Liveness	TCP-проверка порта или `/health`	Ответ по TCP/200

Ротация ключей подписи

Добавить новый ключ подписи
Опубликовать в JWKS (оба ключа активны)
Раскатать обновление
После истечения всех токенов, подписанных старым ключом — удалить старый ключ

Важно

Не меняйте issuer между обычными релизами — это приведёт к инвалидации всех ранее выданных токенов.

Мониторинг и алерты

Рост 5xx ошибок на /auth и /token
Всплеск ошибок invalid_client (нескорректированные клиенты)
Таймауты при подключении к LDAP

Безопасность

HTTPS — обязателен в production
LDAP — используйте ldaps:// или ldap:// + StartTLS
Прокси — должен передавать заголовки X-Forwarded-Proto и X-Forwarded-Host, иначе адрес issuer формируется неверно
Токены — не хранить в localStorage браузера; используйте HttpOnly + Secure cookie

Логи

Компонент	Где смотреть	На что обращать внимание
IDP AM	`/auth`, `/token`	Поля `error`, `error_description`, всплеск `invalid_client`
LDAP	Bind/Search	Таймауты, отказ аутентификации
БД PostgreSQL	Миграции/подключение	Ошибки миграций, ошибки подключения
Прокси	Перед IDP AM	Наличие `X-Forwarded-Proto/Host`

Troubleshooting

Ошибки авторизации (`/auth`)

Симптом	Причина	Решение
`redirect_uri` не совпадает	Адрес возврата не совпадает с зарегистрированным или не абсолютный	Укажите корректный `redirect_uri` в конфигурации
`access_denied` при вводе логина/пароля	Ошибка подключения к LDAP (неверные учётные данные, нет пользователя, таймаут)	Проверьте подключение к LDAP, фильтры и учётные данные

Ошибки при получении токена (`/token`)

Симптом	Причина	Решение
`invalid_client`	Неверные `client_id` или `client_secret`	Проверьте ID и секрет клиента в конфигурации
Некорректный `issuer`	Адрес IDP настроен неверно	Проверьте `issuer` в конфигурации (должен включать базовый путь)

Проблемы с группами и email

Проблема	Причина	Решение
Группы не приходят в токене	Не настроен `groupSearch` или не запрошен scope `groups`	Настройте параметры поиска групп в коннекторе LDAP
Нет email	В LDAP отсутствует атрибут `mail`	Добавьте `emailAttr: mail` и убедитесь, что `mail` заполнен в LDAP
Refresh-токен не выдаётся	Не запрошен scope `offline_access`	Добавьте `offline_access` в список scopes

Проблемы с прокси

Симптом	Причина	Решение
Адрес `issuer` формируется неверно за прокси	Прокси не передаёт `X-Forwarded-Proto/Host`	Прокиньте оба заголовка до IDP AM
После обновления все токены недействительны	Изменился `issuer`	Не меняйте `issuer` при обычных обновлениях

Параметр	dev	stage	prod
TLS (HTTPS)	можно отключить	включён	включён
LDAP-соединение	`ldap://` допустимо	`ldaps://` или `ldap://` + StartTLS	`ldaps://` или `ldap://` + StartTLS
Проверка SSL для LDAP	можно отключить	включена	включена
SSL для PostgreSQL	можно `disable`	`require`/`verify-*`	`require`/`verify-*`
Секреты в YAML	запрещено	запрещено	запрещено
Статические пользователи	допустимо	отключить	отключить
Заголовки прокси	желательно	обязательно	обязательно

Авторизация

Значения по умоланию

Identity Provider

Поток входа

Ключевые адреса

Для пользователей — Вход в систему

Методы авторизации

Единый вход (SSO)

Роли

Для администраторов — Настройка

Установка и запуск

Конфигурация IDP

Структура конфигурации

Конфигурация для первичного входа

Конфигурация для рабочего режима

Переопределение через переменные окружения

Подключение коннекторов

Статический пользователь (нулевой администратор)

Пошаговый сценарий настройки

Управление ролями и маппинг групп

Рекомендации по окружениям

Миграция с Keycloak

Когда нужна миграция

Ключевые отличия

Переходный вариант: OIDC-коннектор к Keycloak

Шаги миграции

Эксплуатация (SRE)

Проверки доступности

Ротация ключей подписи

Мониторинг и алерты

Безопасность

Логи

Troubleshooting

Ошибки авторизации (/auth)

Ошибки при получении токена (/token)

Проблемы с группами и email

Проблемы с прокси

Ошибки авторизации (`/auth`)

Ошибки при получении токена (`/token`)