PGadmin4 в Kubernetes: сессия недействительна при использовании ELB

У меня странная проблема с PGAdmin4.

Моя настройка

  • pgadmin 4.1 развернут на kubernetes с использованием chorss/docker-pgadmin4 образ. Один POD только для упрощения поиска неисправностей;
  • Nginx ingress controller в качестве обратного прокси на кластере;
  • Classic ELB впереди для балансировки нагрузки входящего трафика на кластере.

ELB <=> NGINX <=> PGADMIN

С точки зрения DNS, имя хоста pgadmin - это CNAME в направлении ELB.

Эта проблема

Приложение доступно, пользователи могут войти, и все работает просто отлично. Проблема в том, что через пару (примерно 2-3) минут сеанс становится недействительным, и пользователям предлагается снова войти в систему. Это происходит независимо от того, активно ли используется pgadmin или нет.

После бесчисленных часов устранения неполадок я обнаружил, что проблема возникает, когда DNS-разрешение CNAME ELB переключается на другой IP-адрес.

На самом деле я пытался:

  • подключение к стручку напрямую, подключив к k8s serviceпорт узла напрямую => сеанс не истекает;
  • присоединенный к nginx (в обход ELB) напрямую => сеанс не истекает;
  • сопоставление одного из IP-адресов ELB в моем файле hosts => сеанс не истекает.

Учитывая приведенный выше тест, я бы пришел к выводу, что приложение Flask (PGAdmin4, очевидно, является приложением Python Flask) считает мой cookie недействительным после изменения удаленного адреса для моего имени хоста.

Любой разработчик Flask, который может помочь мне решить эту проблему? Любая другая идея о чем-то, что я мог бы упустить?

Источник

3 ответа

PGadmin 4, кажется, использует Flask-Security для аутентификации:

pgAdmin использовал модуль Flask-Security для управления безопасностью приложений и пользователями, а также предоставляет опции для самостоятельного сброса пароля, смены пароля и т. д.

https://www.pgadmin.org/docs/pgadmin4/dev/code_overview.html

Flask-Security, кажется, использует Flask-Login:

Многие из этих функций стали возможными благодаря интеграции различных расширений и библиотек Flask. Они включают в себя: Flask-Login...

https://pythonhosted.org/Flask-Security/

Flask-Login, кажется, имеет функцию под названием "защита сеанса":

Когда защита сеанса активна, каждый запрос генерирует идентификатор для компьютера пользователя (в основном, безопасный хэш IP-адреса и пользовательский агент). Если у сеанса нет связанного идентификатора, сгенерированный будет сохранен. Если у него есть идентификатор, и он соответствует сгенерированному, тогда запрос в порядке.

https://flask-login.readthedocs.io/en/latest/

Я бы предположил настройку login_manager.session_protection = None решил бы проблему, но, к сожалению, я не знаю, как установить его в PGadmin. Надеюсь, это поможет вам.

Источник

Для тех, кто ищет решение, вам нужно добавить ниже в config.py или config_distro.py или config_local.py

config_local.py

SESSION_PROTECTION = None
Источник

Столкнулся с аналогичной проблемой в балансировщике нагрузки GKE. Более чистое решение, которое сработало для меня, — это отключение защиты файлов cookie на основе IP-адреса. Добавьте флаг ниже в config_local.py

      #Disable Cookie generation base on Ip address 
ENHANCED_COOKIE_PROTECTION = False
Источник
Другие вопросы по тегам