Траблшутинг доступа

Проверка подключения LDAP, OIDC, назначений прав, kubeconfig.

Не удаётся войти в GUI/CLI #

• Если входите с правами рутового администратора, проверьте учётные данные (логин, пароль);
• Если входите с учетными данными пользователя из внешнего каталога (LDAP/OIDC 2.0): — проверьте учётные данные (логин, пароль); — войдите с правами рутового администратора (или обратитесь к администратору), проверьте, что интеграция с внешним каталогом настроена и проверка подключения проходит;
• Проверьте, что в платформе существуют назначения на пользователя - права доступа, прописанные во внешнем каталоге, не создают назначений в платформе;

Не удаётся войти в GUI #

• Проверьте URL (домен, HTTPS);
• Проверьте учётные данные, LDAP-интеграцию или внешний провайдер аутентификации;
• В интерфейсе командной строки проверьте доступность Ingress и сервисов shturval-frontend, shturval-backend.
• Если после ввода корректных учётных данных снова без перерыва переоткрывается форма аутентификации, см. Восстановить вход в графический интерфейс.

Пользователь не находится при поиске #

• Проверьте, что интеграция с LDAP сохранена и проверка подключения проходит.
• Проверьте базовый DN для поиска пользователей и групп.
• Проверьте фильтры поиска и атрибуты: имя пользователя (uid, sAMAccountName), имя группы (cn), email (mail или userPrincipalName для Active Directory), а также атрибуты связи пользователя и группы.
• Выполните ldapsearch вручную с теми же URL сервера, DN подключения, паролем и базовым DN, которые указаны в платформе:

ldapsearch -H ldap://IP-СЕРВЕРА -b "ou=Users,dc=example,dc=com" -D "cn=admin,dc=example,dc=com" -w "ПАРОЛЬ"

• Если используется LDAPS, проверьте порт, TLS, startTLS и CA-сертификат.

Подробнее о параметрах LDAP см. в разделе Интеграция с LDAP.

Группа не находится при поиске #

• Проверьте базовый DN для поиска групп.
• Убедитесь, что атрибут имени группы соответствует настройкам каталога.
• Проверьте блок Сопоставление пользователей и групп в настройках LDAP.
• Если используется внешний OIDC-провайдер, укажите имя группы вручную: при ручном вводе поиск по LDAP не выполняется.

Права не применяются #

• Проверьте статус применения в интерфейсе (красный — ошибки);
• В неймспейсе shturval-backend посмотрите логи пода shturval-permissions-operator, контейнер manager на наличие ошибок;
• Убедитесь, что в назначенном пользователю наборе доступов есть необходимые платформенные разрешения для объектов: создание и байндинг напрямую объектов clusterrole/role не дает доступа к графическому интерфейсу. Назначайте права только через наборы доступов.

Ошибки при подключении к LDAP #

• Проверьте URL, порт, TLS;
• Если включена верификация CA, проверьте загруженный доверенный корневой сертификат;
• Проверьте firewall между платформой и LDAP-сервером.
• Для LDAPS обычно используется порт 636. Для LDAP без защищённого соединения обычно используется порт 389.
• Если включена верификация CA, проверьте загруженный доверенный корневой сертификат.

Подробнее о защищённом подключении см. в разделе Интеграция с LDAP.

Kubeconfig не работает #

Недействительность токена (access token) #

Ошибка: You must be logged in to the server (the server has asked for the client to provide credentials) или couldn't get current server API group list.

Решение:

• Повторно скачайте kubeconfig из графического интерфейса;
• Или используйте плагин kubectl-shturval-plugin для повторной загрузки kubeconfig.

Некорректный сертификат в kubeconfig #

Ошибка: tls: failed to verify certificate: x509: certificate signed by unknown authority — может возникнуть, если в kubeconfig содержится сертификат от другого кластера.

Решение:

• Повторно скачайте kubeconfig из GUI;
• Или загрузите kubeconfig через плагин kubectl-shturval-plugin.

Ошибка экспорта kubeconfig (connection refused localhost:8080) #

Ошибка: The connection to the server localhost:8080 was refused — kubectl пытается подключиться к localhost вместо адреса из kubeconfig.

Решение:

• Экспортируйте kubeconfig в ~/.kube. Если имя файла отлично от config, переименуйте его:

mv /path/to/clustername.conf ~/.kube/config
ls ~/.kube/ | grep config

• Или задайте переменную окружения: export KUBECONFIG=/path/to/clustername.conf.

Ошибка синхронизации времени #

Ошибка: x509: certificate has expired or is not yet valid: current time ... is before ... — расхождение времени между клиентом и сервером.

Решение:

• Включите синхронизацию по NTP. Проверка и настройка:

timedatectl timesync-status   # Проверить NTP
timedatectl set-ntp on        # Включить синхронизацию
timedatectl                   # Проверить дату и время

• Убедитесь, что System clock synchronized: yes и NTP service: active.

Общие рекомендации по kubeconfig #

• Токен в kubeconfig имеет ограниченный срок жизни — при истечении скачайте новый или используйте плагин;
• Проверьте, что адрес API в kubeconfig доступен с вашей машины (сеть, firewall);
• Для статического kubeconfig — убедитесь, что сертификаты актуальны.

Ошибка в работе OIDC #

Ошибка: You must be logged in to the server (Unauthorized) — возможные причины:

1. Невалидный CA-сертификат OIDC;
2. Недоступность кластера управления;
3. Недостаточно прав у пользователя.

Действия:

1. Проверьте логи kube-apiserver на Control Plane узлах:

crictl logs $(crictl ps | awk '/kube-apiserver/ {print $1}')

Если в логах: oidc: authenticator not initialized или tls: failed to verify certificate: x509: certificate signed by unknown authority — проблема с CA-сертификатом OIDC.

2. Если ошибка из-за CA-сертификата: получите валидный CA-сертификат (содержится в ConfigMap root-ca неймспейса cert-manager), добавьте его на Control Plane узлы в /etc/ssl/certs/oidc.crt. При отсутствии доступа к ConfigMap обратитесь к администратору кластера.

3. Если проблема не с сертификатом: проверьте доступность кластера управления; при валидном сертификате и доступном кластере — запросите у администратора расширение прав.

Отладка OIDC #

При проблемах с входом через Keycloak или Blitz проверьте следующие пункты.

1. Проверка Secret с конфигурацией #

Убедитесь, что конфигурация провайдера попала в Secret:

kubectl get secret auth-idps -n shturval-backend -o yaml

Декодируйте значение ключа с конфигурацией (из вывода -o yaml) и проверьте содержимое:

# Скопируйте base64-значение из kubectl get secret auth-idps -n shturval-backend -o yaml
echo "BASE64_ЗНАЧЕНИЕ" | base64 -d

Проверьте: issuerUrl, client.clientId, client.clientSecret, caBundle (если используется).

2. Логи shturval-auth #

Просмотрите логи сервиса аутентификации:

kubectl logs -n shturval-backend -l app=shturval-auth --tail=200 -f

Ищите сообщения об ошибках: invalid_client, redirect_uri_mismatch, invalid_grant, таймауты, ошибки TLS.

3. Доступность URL провайдера #

Проверьте, что платформа может достучаться до провайдера:

# Из пода в shturval-backend
kubectl exec -n shturval-backend deploy/shturval-auth -- curl -s -o /dev/null -w "%{http_code}" https://keycloak.example.ru/realms/shturval/.well-known/openid-configuration

Ожидается 200. При ошибках TLS — проверьте caBundle или insecureSkipVerify.

4. Redirect URI #

Redirect URI в провайдере должен точно совпадать с URL, на который провайдер перенаправляет после входа. Обычно это:

• https://<URL-платформы>/auth/callback или
• https://<URL-платформы>/* (если провайдер поддерживает wildcard)

Проверьте в настройках клиента Keycloak/Blitz: Valid redirect URIs и Web origins.

5. client_id и client_secret #

• client_id — должен совпадать с Client ID в провайдере.
• client_secret — для confidential client должен быть актуальным. При смене секрета в провайдере обновите конфигурацию в ShturvalServicePatch и перепримените Patch.

6. Отключение OIDC при сбое провайдера #

Если провайдер недоступен и войти невозможно:

1. Создайте ShturvalServicePatch с AUTH_IDP_ACTIVE: false.
2. Важно: patchOrder у патча отключения должен быть меньше, чем у патча с конфигурацией OIDC, чтобы отключение применилось первым.
3. Примените Patch и дождитесь перезапуска shturval-auth.
4. Войдите через внутреннюю форму аутентификации (если SKIP_INTERNAL_AUTH_FORM: false).

7. Типичные ошибки #

Отсутствие доступа к API-серверу #

Ошибка: The connection to the server ХХХ.ХХХ.ХХХ.ХХХ:6443 was refused - did you specify the right host or port?

Причины: API-сервер не работает, перезапускается или заблокирован (firewall, сеть).

Действия: Обратитесь к администратору платформы или кластера для выяснения причин.

Плагин не подключается #

• Проверьте URL платформы и учётные данные в конфигурации;
• Убедитесь, что с вашей машины доступен API платформы;
• Проверьте версию плагина и совместимость с версией платформы.