Проблемы и обходные пути
Этот раздел содержит список наиболее распространенных проблем и обходных путей их решения.
Общие проблемы
Не удается запустить "Панели мониторинга"
Если при запуске появляется ошибка FATAL Error: Request Timeout after 30000ms, запустить "Панели мониторинга" на более мощном компьютере. Рекомендуется использовать четыре ядра процессора и 8 ГБ оперативной памяти.
Запросы к "Панелям мониторинга" не выполняются с ошибкой "Request must contain a osd-xsrf header"
Если запускать устаревшие скрипты Kibana OSS для "Панелей мониторинга", например, команды curl, которые импортируют сохраненные объекты из файла, они могут завершиться ошибкой со следующим сообщением:
{"status": 400, "body": "Request must contain a osd-xsrf header."}
В этом случае скрипты, скорее всего, содержат заголовок "kbn-xsrf: true". Рекомендуется переключить его на заголовок osd-xsrf: true:
curl -XPOST -u 'admin:<custom-admin-password>' 'https://DASHBOARDS_ENDPOINT/api/saved_objects/_import' -H 'osd-xsrf:true' --form file=@export.ndjson
Проблемы с несколькими пользователями в "Панелях мониторинга"
Если тестируются несколько пользователей в "Панелях мониторинга" и происходят неожиданные изменения в работе клиента, используют Google Chrome в режиме "инкогнито" или Firefox в приватном режиме.
Сертификаты с истекшим сроком действия
Если срок действия сертификатов истек, можно получить следующую ошибку или что-то подобное:
ERROR org.opensearch.security.ssl.transport.SecuritySSLNettyTransport – Exception during establishing a SSL connection: javax.net.ssl.SSLHandshakeException: PKIX path validation failed: java.security.cert.CertPathValidatorException: validity check failed
Caused by: java.security.cert.CertificateExpiredException: NotAfter: Thu Sep 16 11:27:55 PDT 2021
Чтобы проверить дату истечения срока действия сертификата, нужно выполнить эту команду:
openssl x509 -enddate -noout -in <certificate>
Шифрование в состоянии покоя
Операционная система каждого узла Подсистемы обеспечивает шифрование данных в состоянии покоя. Чтобы включить шифрование в состоянии покоя в большинстве дистрибутивов Linux, используют команду cryptsetup:
cryptsetup luksFormat --key-file <key> <partition>
Невозможно выполнить обновление с помощью скрипта, если активна FLS, DLS или маскировка полей
Плагин Security блокирует обновление с помощью операции скрипта (POST
Нелегальная операция отклоненного доступа в журналах
Это известная проблема с Performance Analyzer, которая не должна влиять на функциональность.
Устранение неполадок securityadmin.sh
В этом разделе приведены инструкции по устранению неполадок для securityadmin.sh. Скрипт можно найти по адресу /plugins/opensearch-security/tools/securityadmin.sh.
Кластер недоступен
Если securityadmin.sh не удается связаться с кластером, выводится:
OpenSearch Security Admin v6
Will connect to localhost:9200
ERR: Seems there is no opensearch running on localhost:9200 – Will exit
Проверить имя хоста
По умолчанию securityadmin.sh использует localhost. Если кластер работает на другом хосте, нужно указать имя хоста с помощью опции -h.
Проверить порт
Следует убедиться, что securityadmin.sh используется для HTTP-порта, а не для транспортного порта.
По умолчанию securityadmin.sh использует 9200. Если кластер работает на другом порту, используют опцию -p для указания номера порта.
Ни один из настроенных узлов не доступен
Если securityadmin.sh может подключиться к кластеру, но не может обновить конфигурацию, выводится следующая ошибка:
Contacting opensearch cluster 'opensearch' and wait for YELLOW clusterstate ...
Cannot retrieve cluster state due to: None of the configured nodes are available: [{#transport#-1}{mr2NlX3XQ3WvtVG0Dv5eHw}{localhost}{127.0.0.1:9300}]. This is not an error, will keep on trying ...
Действия:
- попробовать запустить securityadmin.sh с
-iclи-nhnv; если это помогло, проверить имя кластера, а также имена хостов в сертификатах SSL; если и это не помогло, запустить securityadmin.sh с --diagnose и просмотреть файл журнала диагностики; - добавить
--accept-red-cluster, чтобы разрешить securityadmin.sh работу с "красным" состоянием кластером.
Проверка имени кластера
По умолчанию securityadmin.sh используется opensearch в качестве имени кластера. Если у кластера другое имя, можно либо полностью игнорировать его с помощью опции -icl или указать имя с помощью опции -cn.
Проверка верификации имени хоста
По умолчанию securityadmin.sh проверяет, что имя хоста в сертификате узла совпадает с фактическим именем хоста узла. Если это не так (например, если используются демонстрационные сертификаты), можно отключить проверку имени хоста, добавив параметр -nhnv.
Проверка состояния кластера
По умолчанию securityadmin.sh выполняется только в том случае, если состояние кластера по крайней мере "желтое". Если состояние кластера — "красное", все равно можно выполнить securityadmin.sh, но нужно добавить опцию -arc.
Проверка названия индекса безопасности
По умолчанию плагин Security использует .opendistro_security в качестве имени индекса конфигурации. Если настроено другое имя индекса в opensearch.yml, следует указать его с помощью опции -i.
“ERR: DN is not an admin user”
Если сертификат TLS, используемый для запуска securityadmin.sh, не является сертификатом администратора, скрипт выводит:
Connected as CN=node-0.example.com,OU=SSL,O=Test,L=Test,C=DE
ERR: CN=node-0.example.com,OU=SSL,O=Test,L=Test,C=DE is not an admin user
При выполнении скрипта необходимо использовать сертификат администратора.
Использование опции диагностики
Для получения дополнительной информации о том, почему securityadmin.sh не выполняется, рекомендуется добавить опцию --diagnose:
./securityadmin.sh -diagnose -cd ../../../config/opensearch-security/ -cacert ... -cert ... -key ... -keypass ...
Скрипт выводит местоположение сгенерированного диагностического файла.
Устранение неполадок TLS
Этот раздел содержит инструкции по устранению неполадок для настройки сертификатов TLS с помощью плагина Security.
Проверка YAML
opensearch.yml и файлы в config/opensearch-security/ находятся в формате YAML. Такой инструмент, как YAML Validator, может помочь убедиться, что нет ошибок форматирования.
Просмотр содержимого сертификатов PEM
Можно использовать OpenSSL для отображения содержимого каждого сертификата PEM:
openssl x509 -subject -nameopt RFC2253 -noout -in node1.pem
Затем следует убедиться, что значение совпадает с тем, что указано в opensearch.yml.
Для получения более полной информации о сертификате:
openssl x509 -in node1.pem -text -noout
Проверка наличия специальных символов и пробелов в DN
Плагин Security использует строковое представление отличительных имен (RFC1779) при проверке сертификатов узлов.
Если в DN есть специальные символы (например, запятая), следует убедиться, что они экранированы в конфигурации:
plugins.security.nodes_dn:
– 'CN=node-0.example.com,OU=SSL,O=My\, Test,L=Test,C=DE'
Возможен пробел внутри поля, но не между полями.
Неверный вариант конфигурации:
plugins.security.nodes_dn:
– 'CN=node-0.example.com, OU=SSL,O=My\, Test, L=Test, C=DE'
Верный вариант конфигурации:
plugins.security.nodes_dn:
– 'CN=node-0.example.com,OU=SSL,O=My\, Test,L=Test,C=DE'
Проверка IP-адресов сертификатов
Иногда IP-адрес в сертификате не совпадает с адресом, по которому происходит связь с кластером. Эта проблема может возникнуть, если у узла несколько интерфейсов или он работает в сети с двумя стеками (IPv6 и IPv4).
Если возникнет эта проблема, можно увидеть следующее в журнале Подсистемы узла:
SSL Problem Received fatal alert: certificate_unknown javax.net.ssl.SSLException: Received fatal alert: certificate_unknown
Также можно увидеть следующее сообщение в главном журнале кластера, когда новый узел попытается присоединиться к кластеру:
Caused by: java.security.cert.CertificateException: No subject alternative names matching IP address 10.0.0.42 found
Следует проверить IP-адрес в сертификате:
IPAddress: 2001:db8:0:1:1.2.3.4
В этом примере узел пытается подключиться к кластеру с IPv4-адресом 10.0.0.42, но сертификат содержит IPv6-адрес 2001:db8:0:1:1.2.3.4.
Проверка цепочки сертификатов
Сертификаты TLS организованы в цепочку сертификатов. Можно проверить с помощью keytool правильность цепочки сертификатов, просмотрев владельца и эмитента каждого сертификата.
Проверка настроенного псевдонима
Если в хранилище ключей несколько записей и используются псевдонимы для обращения к ним, следует убедиться, что настроенный псевдоним в opensearch.yml совпадает с псевдонимом в хранилище ключей. Если в хранилище ключей только одна запись, не нужно настраивать псевдоним.
Просмотр содержимого хранилища ключей и сертификатов
Чтобы просмотреть информацию о сертификатах, хранящихся в хранилище ключей или хранилище доверенных сертификатов, используют команду keytool следующим образом:
keytool -list -v -keystore keystore.jks
keytool запрашивает пароль хранилища ключей и выводит список всех записей. Например, можно использовать этот вывод для проверки правильности настроек SAN и EKU.
Проверка имени хостов SAN и IP-адреса
Допустимые имена хостов и IP-адреса сертификатов TLS хранятся в виде записей SAN . Следует убедиться, что записи имени хоста и IP-адреса в разделе SAN верны, особенно если используется проверка имени хоста:
Certificate[1]:
Owner: CN=node-0.example.com, OU=SSL, O=Test, L=Test, C=DE
...
Extensions:
...
#5: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
DNSName: node-0.example.com
DNSName: localhost
IPAddress: 127.0.0.1
...
]
Проверка OID для сертификатов узлов
Если используются OID для обозначения действительных сертификатов узлов, следует убедиться, что расширение SAN для сертификата узла содержит правильный OIDName:
Certificate[1]:
Owner: CN=node-0.example.com, OU=SSL, O=Test, L=Test, C=DE
...
Extensions:
...
#5: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
...
OIDName: 1.2.3.4.5.5
]
Проверка поля EKU на наличие сертификатов узла
В расширенном поле использования ключей сертификатов узлов должны быть указаны serverAuth и clientAuth:
#3: ObjectId: 2.5.29.37 Criticality=false
ExtendedKeyUsages [
serverAuth
clientAuth
]
Версии TLS
Плагин Security по умолчанию отключает TLS версии 1.0; она устарела, небезопасна и уязвима. Если нужно использовать TLSv1 и риски известны, можно включить его в opensearch.yml:
plugins.security.ssl.http.enabled_protocols:
– "TLSv1"
– "TLSv1.1"
– "TLSv1.2"
Поддерживаемые шифры
TLS предполагает, что сервер и клиент согласовывают общий набор шифров. В зависимости от приложения доступные шифры могут различаться. Они зависят от используемой версии JDK или OpenSSL, а также от того, установлены ли "JCE Unlimited Strength Jurisdiction Policy Files".
По юридическим причинам JDK не включает надежные шифры, такие как AES256. Чтобы использовать надежные шифры, нужно скачать и установить расширение Java Cryptography Extension (JCE) с неограниченной юрисдикцией. Если они не установлены, при запуске может появиться сообщение об ошибке:
[INFO ] AES-256 not supported, max key length for AES is 128 bit.
That is not an issue, it just limits possible encryption strength.
To enable AES 256 install 'Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files'
Плагин Security по-прежнему работает и возвращается к более слабым наборам шифров. Плагин также выводит все доступные наборы шифров во время запуска:
[INFO ] sslTransportClientProvider:
JDK with ciphers [TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, ...]
Устранение неполадок SAML
В этом разделе описаны действия по устранению неполадок при использовании SAML для аутентификации в "Панелях мониторинга".
Проверка sp.entity_id
Большинство поставщиков идентификационных данных (IdP) позволяют настраивать несколько методов аутентификации для разных приложений. Например, в Okta эти клиенты называются "приложениями". В Keycloak они называются "клиентами". У каждого из них есть свой идентификатор. Следует убедиться, что sp.entity_id соответствует этим настройкам:
saml:
...
http_authenticator:
type: 'saml'
challenge: true
config:
...
sp:
entity_id: opensearch-dashboards-saml
Проверка URL-адреса потребительской службы утверждения SAML
После успешного входа в систему IdP отправляет ответ SAML с помощью HTTP-директивы POST на "URL-адрес службы утверждений" (ACS) "Панелей мониторинга".
Endpoint, которую предоставляет плагин безопасности "Панелей мониторинга":
/_opendistro/_security/saml/acs
Следует убедиться, что эта endpoint правильно настроена в своем IdP. Некоторые IdP также требуют, чтобы были добавлены все endpoint в список разрешенных, на которые они отправляют запросы. Следует убедиться, что конечная точка ACS включена в этот список.
Для "Панелей мониторинга" также необходимо добавить эту endpoint в список разрешенных. Следует убедиться, что есть следующая запись в opensearch_dashboards.yml:
server.xsrf.allowlist: [/_opendistro/_security/saml/acs]
Настройки ролей
Включение ролей пользователей в ответ SAML зависит от IdP. Например, в Keycloak этот параметр находится в секции "Mappers" клиента. В Okta необходимо установить атрибуты группы. Следует убедиться, что все настроено правильно и что roles_key в конфигурации SAML соответствует имени роли в ответе SAML:
saml:
...
http_authenticator:
type: 'saml'
challenge: true
config:
...
roles_key: Role
Проверка ответа SAML
Если неизвестно, что содержит ответ SAML IdP и где он размещает имя пользователя и роли, можно включить режим отладки в log4j2.properties:
logger.token.name = com.amazon.dlic.auth.http.saml.Token
logger.token.level = debug
Этот параметр выводит ответ SAML в файл журнала Подсистемы, чтобы можно было его проверить и отладить. При установке этого параметра в debug генерируется много сообщений, поэтому не рекомендуется использовать его в рабочей среде.
Другой способ проверки ответа SAML — мониторинг сетевого трафика при входе в "Панели мониторинга". IdP использует HTTP-запросы POST для отправки ответов SAML в кодировке Base64:
/_opendistro/_security/saml/acs
Следует изучить полезную нагрузку этого POST-запроса и использовать такой инструмент, как base64decode.org, чтобы расшифровать его.
Проверка сопоставления ролей
Плагин Security использует стандартное сопоставление ролей для сопоставления роли пользователя или серверной роли с одной или несколькими ролями Security.
Для имени пользователя плагин Security по умолчанию использует атрибут NameID ответа SAML. Для некоторых IdP этот атрибут содержит не ожидаемое имя пользователя, а некий внутренний идентификатор пользователя. Следует проверить содержимое ответа SAML, чтобы найти элемент, который требуется использовать в качестве имени пользователя, и настроить его, задав subject_key:
saml:
...
http_authenticator:
type: 'saml'
challenge: true
config:
...
subject_key: preferred_username
Чтобы проверить, что в ответе SAML указаны правильные серверные роли, нужно просмотреть содержимое и задать правильное имя атрибута:
saml:
...
http_authenticator:
type: 'saml'
challenge: true
config:
...
roles_key: Role
Проверка JWT-токена
Плагин Security заменяет ответ SAML на более легкий веб-токен JSON. Имя пользователя и серверные роли в JWT в конечном итоге сопоставляются с ролями в плагине Security. Если с сопоставлением возникают проблемы, можно включить режим отладки токена с помощью той же настройки, что и при проверке ответа SAML.
Этот параметр выводит JWT в файл журнала Подсистемы, чтобы можно было проверить и отладить его с помощью такого инструмента, как JWT.io.
Устранение неполадок OpenID Connect
Этот раздел содержит инструкции по устранению неполадок при использовании OpenID Connect с подключаемым плагином Security.
Установка уровня журнала для отладки
Чтобы устранить неполадки с OpenID Connect, нужно установить уровень ведения журнала debug в Подсистеме, добавив следующие строки в config/log4j2.properties и перезапустив узел:
logger.securityjwt.name = com.amazon.dlic.auth.http.jwt
logger.securityjwt.level = trace
Этот параметр выводит в файл журнала много полезной информации. Если этой информации недостаточно, также можно установить уровень ведения журнала на trace.
“Failed when trying to obtain the endpoints from your IdP”
Эта ошибка указывает на то, что плагин Security не может подключиться к endpoint метаданных IdP. В opensearch_dashboards.yml следует проверить следующие настройки:
plugins.security.openid.connect_url: "http://keycloak.example.com:8080/auth/realms/master/.well-known/openid-configuration"
Если эта ошибка возникает в Подсистемы, необходимо проверить следующий параметр в config.yml:
openid_auth_domain:
enabled: true
order: 1
http_authenticator:
type: "openid"
...
config:
openid_connect_url: http://keycloak.examplesss.com:8080/auth/realms/master/.well-known/openid-configuration
...
“ValidationError: child ‘opensearch_security’ fails"
Эта ошибка означает, что отсутствует один или несколько параметров конфигурации "Панелей мониторинга". Следует проверить opensearch_dashboards.yml и убедиться, что установлена следующая минимальная конфигурация:
plugins.security.openid.connect_url: "..."
plugins.security.openid.client_id: "..."
plugins.security.openid.client_secret: "..."
“Authentication failed. Please provide a new token."
Эта ошибка имеет несколько потенциальных первопричин.
Оставшиеся файлы cookie или кешированные учетные данные
Следует удалить все сохраненные данные браузера или повторить попытку в приватном окне браузера.
Неверный секрет клиента
Чтобы обменять токен доступа на токен идентификации, большинство IdP требуют предоставить секрет клиента. Следует убедиться, что секрет клиента в opensearch_dashboards.yml совпадает с секретом клиента в конфигурации его IdP:
plugins.security.openid.client_secret: "..."
“Failed to get subject from JWT claims”
Эта ошибка регистрируется в Подсистеме и означает, что имя пользователя не удалось извлечь из токена идентификатора. Следует убедиться, что следующая настройка соответствует требованиям в JWT, которые выдает IdP:
openid_auth_domain:
enabled: true
order: 1
http_authenticator:
type: "openid"
...
config:
subject_key: <subject key>
...
“Failed to get roles from JWT claims with roles_key”
Эта ошибка указывает на то, что ключ ролей, который настроен в config.yml, не существует в JWT, выданном IdP. Следует убедиться, что следующая настройка соответствует утверждениям в JWT, выданном IdP:
openid_auth_domain:
enabled: true
order: 1
http_authenticator:
type: "openid"
...
config:
roles_key: <roles key>
...