Настройка аутентификации через Kerberos
Общие сведения
Kerberos - это сетевой протокол аутентификации, разработанный для безопасного подтверждения личности пользователей и сервисов. Протокол использует симметричное шифрование и доверенные центры распределения ключей (KDC - Key Distribution Center). Один из популярных вариантов использования Kerberos - обеспечение механизма единого входа (SSO), который позволяет избежать многократного ввода пароля для различных сервисов.
Механизм работы
Kerberos-аутентификация реализуется через внешний прокси-сервер (например, Apache или Nginx), расположенный перед сервером веб-интерфейса. Прокси выполняет проверку Kerberos-токена пользователя и передает результат аутентификации в виде HTTP-заголовка в сервис веб-интерфейса, который настроен в режиме доверия к прокси.
Схема работы:
- Пользователь переходит в браузере по URL-адресу веб-интерфейса Smart Monitor, например
company.smartmonitor.ru. Запрос поступает на прокси-сервер - Прокси-сервер отправляет ответ с кодом 401 (Unauthorized) и заголовком
WWW-Authenticate: Negotiate, предлагая Kerberos-аутентификацию по протоколу SPNEGO - Браузер, если он поддерживает Kerberos и хост, с которого происходит обращение, находится в домене, совершает следующие операции:
- автоматически запрашивает Kerberos-билет (TGS) у KDC сервера для сервиса, например,
HTTP/COMPANY.SMARTMONITOR.RU@CORP.RU - возвращает билет прокси-серверу в заголовке:
Authorization: Negotiate <base64-кодированный Kerberos-токен>
- автоматически запрашивает Kerberos-билет (TGS) у KDC сервера для сервиса, например,
- Прокси-сервер, использует локальные библиотеки GSSAPI и выданный администратором keytab-файл для проверки подлинности токена:
- читает локальную конфигурацию работы с Kerberos из
/etc/krb5.conf, чтобы корректно интерпретировать Kerberos-билет (realm, DNS и т.д.) - извлекает имя пользователя из токена (например,
petrov.p@CORP.RU)
- читает локальную конфигурацию работы с Kerberos из
- Прокси-сервер добавляет в HTTP-запрос заголовок с именем пользователя (например
x-proxy-user: petrov.p@corp.ru) и перенаправляет запрос на сервис веб-интерфейса - Сервис веб-интерфейса настроен на работу в proxy-режиме, при котором:
- не проверяется базовая аутентификация
- происходит полное доверие значению из заголовка
x-proxy-user, переданного от прокси-сервером - это имя пользователя используется для взаимодействия с узлами Smart Monitor
- Smart Monitor, настроенный в режиме доверия к внешним механизмам аутентификации, получает имя пользователя из заголовка
x-proxy-user, переданного от сервиса веб-интерфейса, и использует его как backend роль
Убедитесь, что прямой доступ пользователей к сервису веб-интерфейса и узлам Smart Monitor (в обход прокси-сервера) заблокирован на уровне сети, например, с помощью межсетевого экрана или правил маршрутизации.
В противном случае злоумышленник может отправить запрос напрямую к сервису веб-интерфейса или узлам Smart Monitor с поддельным заголовком x-proxy-user, что приведет к обходу механизма аутентификации.
Некоторые меры защиты будут описаны в статье далее.
Предварительные требования
Используемы файлы
- keytab-файл - содержит зашифрованные учетные данные сервиса Kerberos, которые прокси-сервер использует для проверки подлинности входящих Kerberos-токенов. Этот файл создается средствами Active Directory или ktutil системным администратором, ответственным за службу каталогов
- SSL-сертификат и приватный ключ (в формате PEM) - сертификат, используемый прокси-сервером для организации HTTPS-соединения между браузером пользователя и сервером. Сертификат следует подписывать доверенным удостоверяющим центром домена организации, чтобы избежать предупреждений о безопасности и обеспечить корректную работу механизма SPNEGO во всех браузерах
Прочая информация
- имя Kerberos принципала (SPN) - уникальный идентификатор сервиса, зарегистрированный в Kerberos realm. Для веб-прокси имя принципала имеет вид
HTTP/<SERVICE_FQDN>@<KRB_REALM>, напримерHTTP/COMPANY.SMARTMONITOR.RU@CORP.RU. Это имя должно соответствовать записи в keytab-файле и быть зарегистрировано в KDC - IP-адрес или fqdn сервера KDC - сервер аутентификации (например, контроллер домена Active Directory), который выдает Kerberos-билеты клиентам. Его адрес указывается в файле конфигурации Kerberos (
/etc/krb5.conf) на сервере прокси и используется для валидации входящих токенов
Условные обозначения
OS_IP- IP-адрес мастер-узла Smart MonitorOS_HOME- домашняя директория Smart Monitor, обычно это/app/opensearch/OSD_HOME- домашняя директория Smart Monitor Web, обычно это/app/opensearch-dashboards/CLUSTER_NAME- имя кластера OpenSearchKEYTAB_PATH- полный путь до keytab-файла, используемого прокси для Kerberos-аутентификацииSERVICE_FQDN- полное доменное имя (FQDN) сервиса веб-интерфейса, к которому подключается клиент в браузере (например, company.smartmonitor.ru)KRB_PRINCIPAL- имя Kerberos принципала для сервиса веб-интерфейсаKRB_REALM- имя Kerberos реалма (домен аутентификации, например, EXAMPLE.COM)KDC_IP- IP-адрес сервера Kerberos (KDC), часто совпадает с адресом контроллера доменаSSL_CERT- путь к SSL-сертификату сервера (в формате PEM), используемому проксиSSL_KEY- путь к приватному ключу для указанного SSL-сертификата (формат PEM)
Убедитесь, что значения параметров SERVICE_FQDN и KRB_REALM образуют значение параметра KRB_PRINCIPAL по следующей схеме:
HTTP/<SERVICE_FQDN>@<KRB_REALM>
Обратите внимание, что в некоторых командах bash в рамках статьи используется подстановка значений условных обозначений в формате переменных оболочки (${SYMBOL} вместо <SYMBOL>). Перед выполнением такой команды выполните установку соответствующей переменной в оболочке:
SYMBOL=<SYMBOL>
Настройка локальной конфигурации Kerberos
Перед тем как настраивать прокси сервер, сначала необходимо установить пакет krb5. Установка пакета производится на сервере, на котором будет развернут прокси. Прокси может быть развернут на том же сервере, на котором запущен сервис веб-интерфейса (Smart Monitor Web).
Пакет krb5 (Kerberos 5) предоставляет основные библиотеки и утилиты для работы с протоколом Kerberos.
Выполните следующие команды для установки пакета krb5:
sudo apt update
sudo apt install krb5-user
На этапе установки отобразится экран Pending kernel upgrade, для продолжения нажмите Space на клавиатуре.
Далее появится экран Daemons using outdated libraries.
Необходимо убрать отметки * на всех выделенных сервисах. Для снятия отметки с пункта воспользуйтесь клавией Space. Для перемещения между пунктами используйте стрелки.
После снятия всех отметок нажмите Enter. На этом установка будет закончена.
По завершении установки в директории /etc должен появиться файл конфигурации с именем krb5.conf. Данный файл используется модулем прокси mod_auth_gssapi, который участвует в процессе обработки запроса с Kerberos учетными данными.
Этот файл необходимо настроить для того, чтобы библиотека GSSAPI, используемая Apache, могла корректно определить параметры Kerberos-сервера (KDC), реалм и правила сопоставления доменов.
Откройте файл /etc/krb5.conf для редактирования и задайте следующее содержимое:
[libdefaults]
default_realm = <KRB_REALM>
dns_lookup_realm = true
dns_lookup_kdc = true
[realms]
<KRB_REALM> = {
kdc = <KDC_IP>
admin_server = <KDC_IP>
}
[domain_realm]
.<SERVICE_FQDN> = <KRB_REALM>
<SERVICE_FQDN> = <KRB_REALM>
Конфигурационный файл состоит из следующих частей:
-
[libdefaults]- общие параметрыdefault_realm- имя основного Kerberos-реалма (например,EXAMPLE.COM), к которому по умолчанию будут относиться все пользователи и сервисы. Указывается в верхнем регистреdns_lookup_realmиdns_lookup_kdc- разрешают автоматическое определение реалма и адресов серверов Kerberos через DNS. В большинстве случаев их можно оставить включенными (true)
-
[realms]- параметры реалма Эта секция определяет, как подключаться к конкретному Kerberos реалму.kdc- IP-адрес (или FQDN) сервера KDC, который выдает билетыadmin_server- адрес сервера администрирования Kerberos (обычно совпадает с kdc)
-
[domain_realm]- сопоставление доменов и реалмов Эта секция позволяет Kerberos-клиенту определять, какой реалм использовать для конкретных DNS-доменов.<SERVICE_FQDN> = <KRB_REALM>- означает, что все поддомены*.<SERVICE_FQDN>будут автоматически привязаны к реалму<KRB_REALM>.<SERVICE_FQDN> = <KRB_REALM>- обозначает, что основное доменное имя также привязано к реалму
Эти сопоставления необходимы для корректной работы SPNEGO в браузере клиента - именно по ним Kerberos определяет, какой токен формировать при доступе к веб-сервису.
В разделе [domain_realm] - слева от знака = доменные имена всегда указываются в нижнем регистре, а реалмы справа - всегда в верхнем.
Принципалы (имена сервисов) указываются без реалма (например, HTTP/example.com).
Проверка конфигурации Kerberos и keytab-файла
Для проверки корректности настроенной выше конфигурации и keytab-файла, выданного администратором, можно попробовать запросить TGT-билет.
TGT (Ticket-Granting Ticket) - это основной Kerberos-билет, выдаваемый KDC после успешной аутентификации. Он подтверждает подлинность пользователя или сервиса и используется для получения доступа к другим ресурсам.
Получение TGT необходимо только для проверки. В рабочей схеме прокси не выполняет запросы к KDC напрямую, поэтому постоянная сетевая доступность до KDC не требуется. Этот шаг можно пропустить, если такая проверка невозможна из-за отсутствия сетевой доступности до KDC.
Для получения TGT-билета от имени сервиса выполните команду:
kinit HTTP/<SERVICE_FQDN> -k -t <KEYTAB_PATH>
Описание опций:
-k- использовать keytab-файл вместо пароля-t- путь до keytab-файла
Данная команда инициирует получение TGT от имени указанного принципала.
Далее необходимо проверить полученные билеты следующей командой:
klist
Пример вывода команды:
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: user.u@EXAMPLE.COM
Valid starting Expires Service principal
05/28/25 07:00:32 05/28/25 17:00:32 krbtgt/EXAMPLE.COM@EXAMPLE.COM
renew until 05/29/25 07:00:20
Пояснение вывода команды:
- Ticket cache - путь к файлу, где временно хранится билет
- Default principal - кто именно прошел аутентификацию
- Service principal - KDC, выдавший TGT
- Valid starting / Expires - срок действия TGT
- renew until - крайний срок автоматического продления билета
Если вы успешно получили TGT, это подтверждает, что конфигурация Kerberos настроена корректно и keytab-файл валиден.
Установка и настройка прокси
Следующим шагом необходимо настроить обратный прокси, который будет выполнять Kerberos-аутентификацию входящих HTTP-запросов. В данной инструкции используется веб-сервер Apache.
Для установки Apache необходимо установить пакет apache2. Для этого выполните следующие команды:
sudo apt update
sudo apt install apache2
Далее необходимо создать и настроить конфигурационный файл Apache. Для этого выполните следующую команду:
nano /etc/apache2/sites-available/apache-kerberos.conf
Вставьте в файл следующий шаблон конфигурации и замените параметры на ваши значения:
apache-kerberos.conf
HostnameLookups Off
KeepAlive On
MaxKeepAliveRequests 500
KeepAliveTimeout 5
ProxyPreserveHost On
<VirtualHost *:80>
ServerName <SERVICE_FQDN>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</VirtualHost>
<VirtualHost *:443>
ServerName <SERVICE_FQDN>
LogLevel warn
ErrorLog /var/log/apache2/error.log
CustomLog /var/log/apache2/access.log common
SSLEngine on
SSLCertificateFile /path/to/your/<SSL_CERT>
SSLCertificateKeyFile /path/to/your/<SSL_KEY>
RedirectMatch ^/$ https://<SERVICE_FQDN>/
ProxyRequests Off
ProxyVia On
RemoteIPHeader X-Forwarded-For
<Proxy *>
Require all granted
</Proxy>
SSLProxyEngine on
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off
<Location / >
ProxyPass https://127.0.0.1:5601/
ProxyPassReverse https://127.0.0.1:5601/
RequestHeader set x-proxy-user %{REMOTE_USER}s
RequestHeader set x-proxy-roles %{REMOTE_USER}s
RequestHeader set x-forwarded-for 127.0.0.1
AuthType GSSAPI
AuthName "GSSAPI Login"
GssapiCredStore keytab: <KEYTAB_PATH>
GssapiLocalName On
GssapiAllowedMech krb5
GssapiBasicAuthMech krb5
GssapiConnectionBound on
GssapiUseSessions On
Require valid-user
</Location>
</VirtualHost>
Описание ключевых параметро:
GssapiLocalName On- определяет преобразует форматаuser@REALM->userGssapiAllowedMech krb5- разрешает только Kerberos как механизм аутентификацииGssapiBasicAuthMech krb5- механизм базовой аутентификации (если применяется)GssapiConnectionBound On- привязка сессии к соединениюGssapiUseSessions On- включение кеширования сессий для снижения нагрузки на KDC
Для работы Apache с Kerberos необходимо, чтобы у него был доступ к keytab-файлу:
sudo chmod 644 <KEYTAB_PATH>
Перезапустите службу apache2 и проверьте ее состояние с помощью следующих команд:
sudo systemctl restart apache2
sudo systemctl status apache2
Откройте порт 443 в настройках сетевого экрана.
Для систем на базе RHEL:
sudo firewall-cmd --permanent --zone=public --add-port=443/tcp
sudo firewall-cmd --reload
sudo firewall-cmd --list-all
Для систем на базе Debian:
sudo ufw allow 443/tcp
sudo ufw reload
sudo ufw status verbose
На этом настройка прокси-сервера завершена.
Настройка конфигураций безопасности Smart Monitor
Настройка плагина безопасности Smart Monitor
Перед изменением конфигурации необходимо синхронизировать ее с текущим состоянием кластера. Это позволит избежать потери изменений, сделанных напрямую через API.
Выполните следующую команду:
JAVA_HOME=${OS_HOME}/jdk/ ${OS_HOME}/plugins/opensearch-security/tools/securityadmin.sh -h ${OS_IP} \
-cacert ${OS_HOME}/config/ca-cert.pem \
-cert ${OS_HOME}/config/admin-cert.pem \
-key ${OS_HOME}/config/admin-key.pem \
--accept-red-cluster -nhnv -icl \
-backup ${OS_HOME}/config/opensearch-security/
Данная команда создаст актуальную резервную копию текущей конфигурации в <OS_HOME>/config/opensearch-security/.
Откройте файл конфигурации безопасности config.yml, расположенный в директории <OS_HOME>/config/opensearch-security/:
nano ${OS_HOME}/config/opensearch-security/config.yml
И добавьте в него следующие настройки с учетом текущего содержимого:
config:
dynamic:
http:
anonymous_auth_enabled: false
xff:
enabled: true
remoteIpHeader: "x-forwarded-for"
internalProxies: "127.0.0.1"
authc:
proxy_auth_domain:
http_enabled: true
transport_enabled: true
order: 0
http_authenticator:
type: "proxy"
challenge: false
config:
user_header: "x-proxy-user"
roles_header: "x-proxy-roles"
authentication_backend:
type: "noop"
Параметр config.dynamic.authc.proxy_auth_domain.order обязательно должен быть равен 0. Все остальные схемы аутентификации, если таковые перечисленны в блоке config.dynamic.authc, должны иметь order строго больше 0.
В параметре config.dynamic.http.xff.internalProxies должен быть указан адрес прокси-сервера, который является доверенным. Запросы с этого прокси-сервера считаются аутентифицированными. Значения заголовков (x-proxy-user и x-proxy-roles) запроса, указанных в параметрах user_header и roles_header, будут использоваться в качестве имени и роли аутентифицированного пользователя. Кроме прокси-сервера, никто другой не должен иметь возможность обращаться к Smart Monitor с данными заголовками, в противном случае статус аутентификации может быть подделан.
Для загрузки обновленной конфигурации обратно в кластер выполните команду:
JAVA_HOME=${OS_HOME}/jdk/ ${OS_HOME}/plugins/opensearch-security/tools/securityadmin.sh \
-cacert ${OS_HOME}/config/ca-cert.pem \
-cert ${OS_HOME}/config/admin-cert.pem \
-key ${OS_HOME}/config/admin-key.pem \
--accept-red-cluster --clustername ${CLUSTER_NAME} \
-f ${OS_HOME}/config/opensearch-security/config.yml \
-t config -h ${OS_IP}
Настройка конфигурации Smart Monitor Web
Теперь необходимо сконфигурировать веб-интерфейс Smart Monitor для корректной обработки заголовков прокси.
Откройте файл конфигурации $OSD_HOME/config/opensearch-dashboards.yml и добавьте в его конец следующие параметры:
# ---------------------------- Proxy Authentication ----------------------------
opensearch.requestHeadersWhitelist: ["securitytenant", "Authorization", "x-forwarded-for", "x-proxy-user", "x-proxy-roles"]
smart_monitor.auth.type: "proxy"
smart_monitor.proxycache.user_header: "x-proxy-user"
smart_monitor.proxycache.roles_header: "x-proxy-roles"
Описание параметров:
opensearch.requestHeadersWhitelist- список заголовков, которые разрешено пересылать с клиента в OpenSearch. Здесь обязательно должны быть указаны заголовки, в которых прокси передает имя пользователя и его ролиsmart_monitor.auth.type- задает режим работы Smart Monitor Web. В данном случае задан режим работы с проксиsmart_monitor.proxycache.user_headerиroles_header- определяют, из каких заголовков Smart Monitor должен извлекать информацию о пользователе и его ролях
Для применения изменений перезапустите службу веб-интерфейса:
sudo systemctl restart opensearch-dashboards
На этом настройка конфигураций завершена.
Настройка браузеров для работы с Kerberos
Для корректной работы Kerberos-аутентификации в браузерах необходимо разрешить автоматическую передачу Kerberos-токена для определенных сайтов (в нашем случае - для сайта с веб-интерфейсом Smart Monitor).
Настройка Chrome и Edge
Оба этих браузера используют системные настройки Windows, поэтому конфигурация выполняется через настройки системы.
Выполните следующие действия:
- Нажмите
Win+R, в открывшемся окне введитеinetcpl.cplи нажмитеEnter- откроется окноСвойства: Интернет - Перейдите на вкладку
Безопасность - Нажмите
Местная интрасеть-Сайты - Введите адрес сайта (
<SERVICE_FQDN>в нижнем регистре), нажмитеДобавить, затемЗакрыть
Настройка Firefox
Firefox не использует системные настройки, поэтому настройка необходимо задать в конфигурации браузера.
Выполните следующие действия:
- Откройте Firefox и в адресной строке введите
about:config - Подтвердите предупреждение о внесении изменений
- В поле поиска введите
negotiate - Настройте параметры по аналогии с примером, заменив
smart.localна соответствующее значение вашего<SERVICE_FQDN>(в нижнем регистре):
Если пользователь работает на компьютере, присоединенном к домену, Kerberos TGT будет получен автоматически при входе в систему. Если же компьютер находится вне домена - браузер запросит имя доменного пользователя и пароль при попытке доступа к веб-интерфейсу.
На данном этапе настройка аутентификации через Kerberos завершена.