Версия: 6.2

Настройка Smart Monitor для двухфакторной аутентификации по протоколу OIDC

Это третий из трех этапов настройки. Сначала настройте провайдер Keycloak и клиент Keycloak.

Условные обозначения

Обратите внимание!

Пути с $OS_HOME и $OSD_HOME указывают на файлы соответствующих сервисов. Если сервисы работают на разных серверах, заранее перенесите необходимые файлы между ними.

Базовые адреса зависят от схемы публикации:

Токен	Описание	Прямая публикация	Через прокси
`<KEYCLOAK_BASE>`	базовый адрес Keycloak	`https://<KEYCLOAK_HOST>:8443`	`https://<KEYCLOAK_HOST>/keycloak`
`<OSD_BASE>`	базовый адрес Smart Monitor Web	`https://<OSD_HOST>:5601`	`https://<OSD_HOST>`

Остальные обозначения от схемы публикации не зависят:

Токен	Описание
`<KEYCLOAK_HOST>`	внешнее имя хоста с Keycloak
`<OSD_HOST>`	внешнее имя хоста со Smart Monitor Web
`<KEYCLOAK_CA>`	имя файла CA, которым подписан сертификат стороны, принимающей соединение: прокси, если он есть, иначе самого Keycloak. Копия файла размещается в каталоге конфигурации каждого сервиса отдельно
`<REALM_ID>`	техническое имя realm
`<CLIENT_ID>`	техническое имя клиента, свое на каждый хост
`<CLIENT_SECRET>`	секрет клиента, вкладка `Credentials`
`<COOKIE_PASS>`	ключ шифрования cookie Smart Monitor Web, ≥32 символов
`$OS_HOME`	домашняя директория Smart Monitor Data Storage
`$OSD_HOME`	домашняя директория Smart Monitor Web

Порядок настройки

Шаг 1. Создание резервной копии

cd $OS_HOME/plugins/opensearch-security/tools

sudo OPENSEARCH_JAVA_HOME=$OS_HOME/jdk/ ./securityadmin.sh \
  -backup $OS_HOME/config/security-backup \
  -icl -nhnv \
  -cacert $OS_HOME/config/ca-cert.pem \
  -cert   $OS_HOME/config/admin-cert.pem \
  -key    $OS_HOME/config/admin-key.pem

При успешном выполнении команда выводит девять строк SUCC:. Скопируйте каталог резервной копии за пределы хоста.

Обратите внимание!

Ключ -backup выгружает конфигурацию из индекса, а не из файлов на диске. Поэтому кластер должен быть запущен. Резервную копию достаточно создать один раз для всего кластера на любом узле. Переменная OPENSEARCH_JAVA_HOME передается в той же строке, поскольку sudo очищает переменные окружения.

Шаг 2. Изменение настроек безопасности

Обратите внимание!

Измените config.yml и перенесите CA на каждый узел Smart Monitor Data Storage.

Файл: $OS_HOME/config/opensearch-security/config.yml

2.1 Изменение способа аутентификации

Проверьте значение challenge в домене базовой аутентификации. Если задано challenge: true, замените его на false. Иначе Smart Monitor Data Storage возвращает WWW-Authenticate: Basic, и браузер открывает встроенное окно входа вместо перенаправления на Keycloak. На запросы через curl, Smart Monitor Data Collector и агенты сбора это не влияет: они сами передают заголовок Authorization.

2.2 Добавление домена OIDC

Добавьте домен OIDC в секцию authc после существующих доменов:

      openid_auth_domain:
        description: "Keycloak OIDC"
        http_enabled: true
        transport_enabled: false
        order: 3
        http_authenticator:
          type: "openid"
          challenge: false
          config:
            openid_connect_url: "<KEYCLOAK_BASE>/realms/<REALM_ID>/.well-known/openid-configuration"
            subject_key: "preferred_username"
            roles_key: "groups"
            required_issuer: "<KEYCLOAK_BASE>/realms/<REALM_ID>"
            required_audience: "<CLIENT_ID>"
            openid_connect_idp:
              enable_ssl: true
              pemtrustedcas_filepath: $OS_HOME/config/<KEYCLOAK_CA>
        authentication_backend:
          type: "noop"

Обратите внимание!

roles_key задает claim, из которого извлекаются backend-роли. Без него пользователь, чьи права определяются группами Keycloak, а не AD, войдет без ролей и получит сообщение no permissions.

Изменения файла вступят в силу только после шага 6: действующая конфигурация хранится в индексе .opendistro_security.

Поддерживайте одинаковое содержимое config.yml на всех узлах.

Шаг 3. Маппинг ролей

В большинстве случаев изменять маппинг ролей не требуется. Права назначаются одним из двух способов.

3.1 Через Active Directory

Секция authz: roles_with_ldap применяется к любому аутентифицированному пользователю, в том числе вошедшему через Keycloak. Smart Monitor Data Storage находит его в AD по sAMAccountName, совпадающему с preferred_username, и добавляет группы AD в backend_roles.

3.2 Через совпадение имен

Группа в Keycloak называется так же, как существующая backend_role.

Доступ к интерфейсу обычно уже обеспечен: у роли kibana_user, как правило, задано users: ["*"]. Поэтому она назначается любому аутентифицированному пользователю независимо от наличия записи о нем в roles_mapping.yml.

Шаг 4. Конфигурация Smart Monitor Web

Добавьте блок в конец конфигурации. Существующие параметры не изменяйте.

Сгенерируйте ключ для cookie:

head -c 48 /dev/urandom | base64 | tr -d '/+=' | head -c 48; echo

Файл: $OSD_HOME/config/opensearch_dashboards.yml

# 2FA
smart_monitor.auth.multiple_auth_enabled: true
smart_monitor.auth.type: ["openid", "basicauth"]

smart_monitor.openid.connect_url: "<KEYCLOAK_BASE>/realms/<REALM_ID>/.well-known/openid-configuration"
smart_monitor.openid.logout_url: "<KEYCLOAK_BASE>/realms/<REALM_ID>/protocol/openid-connect/logout"
smart_monitor.openid.client_id: "<CLIENT_ID>"
smart_monitor.openid.client_secret: "<CLIENT_SECRET>"
smart_monitor.openid.root_ca: "$OSD_HOME/config/<KEYCLOAK_CA>"
smart_monitor.openid.base_redirect_url: "<OSD_BASE>"
smart_monitor.openid.scope: "openid profile email"

smart_monitor.cookie.secure: true
smart_monitor.cookie.password: "<COOKIE_PASS>"
smart_monitor.cookie.ttl: 3600000
smart_monitor.session.ttl: 3600000
smart_monitor.session.keepalive: true

smart_monitor.ui.openid.login.buttonname: "Вход через 2FA"
smart_monitor.ui.openid.login.buttonstyle: "ouiButton--fill btn-login"

smart_monitor.openid.root_ca указывает на тот же CA, что и pemtrustedcas_filepath в шаге 2. При этом в каталоге конфигурации Smart Monitor Web нужна отдельная копия файла: процесс использует собственный список доверенных сертификатов.

Сохраняйте smart_monitor.cookie.secure: true при обеих схемах публикации. При использовании прокси Smart Monitor Web принимает соединения по HTTP, но браузер работает по HTTPS. Без этого параметра cookie не сохранится.

Чтобы разрешить только вход через 2FA, замените первые две строки блока на:

smart_monitor.auth.multiple_auth_enabled: false
smart_monitor.auth.type: ["openid"]

Целевая схема: доменные пользователи входят только со вторым фактором, а сервисные учетные записи — по паролю. Для этого в файле $OS_HOME/config/opensearch-security/config.yml в блоке ldap замените http_enabled: true на false. Последствия описаны в разделе Замечание по безопасности.

Шаг 5. Прокси перед Smart Monitor Web

Только при работе через прокси

Шаг выполняется только в схеме с прокси. При прямой публикации он пропускается целиком.

Ниже приведен пример настройки nginx на хосте со Smart Monitor Web.

Для id_token задайте размеры буферов в блоке location / перед Smart Monitor Web:

proxy_buffer_size        32k;
proxy_buffers          8 32k;
proxy_busy_buffers_size  64k;

На уровне http или server задайте:

large_client_header_buffers 8 32k;

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

Правило для кнопки входа через SSO описано в разделе Кнопка входа через SSO.

nginx -t && systemctl reload nginx

Шаг 6. Применение конфигурации Smart Monitor Data Storage

cd $OS_HOME/plugins/opensearch-security/tools

sudo OPENSEARCH_JAVA_HOME=$OS_HOME/jdk/ ./securityadmin.sh \
  -f $OS_HOME/config/opensearch-security/config.yml -t config \
  -icl -nhnv \
  -cacert $OS_HOME/config/ca-cert.pem \
  -cert   $OS_HOME/config/admin-cert.pem \
  -key    $OS_HOME/config/admin-key.pem

Выполните команду один раз на любом узле: конфигурация применится ко всему кластеру. Запускать ее на каждом узле не требуется.

Перезапускать Smart Monitor Data Storage не требуется: конфигурация применяется динамически. Smart Monitor Web читает файл конфигурации при запуске, поэтому перезапустите его:

systemctl restart opensearch-dashboards

После входа через Keycloak в Навигационное меню - Dev Tools выполните запрос:

GET _plugins/_security/authinfo

В поле user_name указано имя пользователя из Keycloak, в backend_roles — его группы. Если имя верное, но backend_roles пусто, claim groups не передан. Проверьте маппер клиента.

Откат изменений

Важно!

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

На хосте, где создана резервная копия, выполните команду:

cd $OS_HOME/plugins/opensearch-security/tools

sudo OPENSEARCH_JAVA_HOME=$OS_HOME/jdk/ ./securityadmin.sh \
  -cd $OS_HOME/config/security-backup \
  -icl -nhnv \
  -cacert $OS_HOME/config/ca-cert.pem \
  -cert   $OS_HOME/config/admin-cert.pem \
  -key    $OS_HOME/config/admin-key.pem

Ключ -cd загружает все девять файлов конфигурации безопасности. Указывайте с ним только каталог резервной копии. Затем удалите добавленный блок из конфигурации Smart Monitor Web и перезапустите сервис.

Кнопка входа через SSO

Настройка адреса кнопки входа через openid не предусмотрена. Добавьте недостающий маршрут вручную с учетом схемы публикации.

При использовании прокси добавьте правило переадресации. Пример для nginx:

location = /auth/openid/captureUrlFragment {
    if ($args) {
        return 302 /auth/openid/login?$args;
    }
    return 302 /app/overview;
}

Обратите внимание!

При прямой публикации кнопка Вход через 2FA не работает. Откройте страницу входа Keycloak по прямой ссылке: <OSD_BASE>/auth/openid/login?nextUrl=%2Fapp%2Foverview.

Замечание по безопасности

Второй фактор обходится обычной формой входа

Пока в auth.type присутствует basicauth, второй фактор остается необязательным: доменный пользователь может войти без кода. Чтобы второй фактор был обязательным, задайте ["openid"] в Smart Monitor Web и закройте порт 9200 межсетевым экраном. Иначе прямые запросы к API не требуют второго фактора.

Чтобы по паролю могли входить только внутренние учетные записи Smart Monitor Data Storage, а доменные пользователи проходили аутентификацию через Keycloak, отключите LDAP-домен для HTTP-слоя в config.yml:

      ldap:
        http_enabled: false        # было true
        transport_enabled: true

Секцию authz: roles_with_ldap не изменяйте: она отвечает за роли и продолжит добавлять группы AD пользователям из Keycloak. После этого доменные учетные записи не смогут проходить аутентификацию по логину и паролю на :9200.

Условные обозначения​

Порядок настройки​

Шаг 1. Создание резервной копии​

Шаг 2. Изменение настроек безопасности​

2.1 Изменение способа аутентификации​

2.2 Добавление домена OIDC​

Шаг 3. Маппинг ролей​

3.1 Через Active Directory​

3.2 Через совпадение имен​

Шаг 4. Конфигурация Smart Monitor Web​

Шаг 5. Прокси перед Smart Monitor Web​

Шаг 6. Применение конфигурации Smart Monitor Data Storage​

Откат изменений​

Кнопка входа через SSO​

Замечание по безопасности​

Условные обозначения

Порядок настройки

Шаг 1. Создание резервной копии

Шаг 2. Изменение настроек безопасности

2.1 Изменение способа аутентификации

2.2 Добавление домена OIDC

Шаг 3. Маппинг ролей

3.1 Через Active Directory

3.2 Через совпадение имен

Шаг 4. Конфигурация Smart Monitor Web

Шаг 5. Прокси перед Smart Monitor Web

Шаг 6. Применение конфигурации Smart Monitor Data Storage

Откат изменений

Кнопка входа через SSO

Замечание по безопасности