Использование Session Affinity (Cookies) с SSL Passthrough на NGINX-Ingress
TL; DR: Я хочу настроить привязку сеансов на основе файлов cookie в K8s через контроллер nginx-ingress с использованием SSL - можно ли это сделать?
Всем привет,
У меня работает работающая служба Azure Kubernetes (AKS) (1.11.3), и я настроил контроллер NGINX-Ingress для маршрутизации запросов к службе ClusterIP для моего приложения (в котором работает минимум 2 модуля).
Я успешно настроил передачу SSL на входном контроллере, так что TLS завершается на модулях, и я могу использовать HTTP2 (согласно этой статье). Теперь я бы хотел настроить Session Affinity (используя Cookies), чтобы соединения направлялись в один и тот же модуль для отслеживания состояния (вход в приложение).
Я попытался использовать следующие аннотации на входном объекте для этого:
nginx.ingress.kubernetes.io/affinity: "cookie"
nginx.ingress.kubernetes.io/session-cookie-name: "route"
nginx.ingress.kubernetes.io/session-cookie-expires: "172800"
nginx.ingress.kubernetes.io/session-cookie-max-age: "172800"
nginx.ingress.kubernetes.io/session-cookie-hash: "sha1"
Тем не менее, я не вижу cookie "маршрута", возвращенные при первом запросе. Я работал над проблемой, описанной здесь, и убедился, что вход настроен правильно. Затем я заметил это сообщение в документации:
Поскольку SSL Passthrough работает на уровне 4 модели OSI (TCP), а не на уровне 7 (HTTP), использование SSL Passthrough делает недействительными все остальные аннотации, установленные для объекта Ingress.
Вопрос: Значит ли это, что использование схожести сеанса с передачей SSL вне стола? В этом случае Ingress не сможет идентифицировать соединение / cookie (так как он зашифрован SSL) и направить его на ранее связанный модуль?
1 ответ
Краткий ответ: нет, это невозможно. Слой 4 не имеет никакого представления о том, что такое http, он просто видит, как байты текут взад и вперед. Вместо этого у вас может быть сходство, основанное на ip-адресе, но не на cookie-файлах, так как для этого потребуется прокси-решение уровня 7. В зависимости от вашей ситуации, вы можете запустить прокси на уровне 7, который сможет расшифровать трафик, а затем зашифровать его с помощью другого сертификата для внутреннего использования. Вся полезная нагрузка (за исключением SNI, например) не зашифрована в соответствии с SSL, что означает, что для того, чтобы сделать какую-то привязку к cookie-файлам, прокси-сервер должен будет расшифровать данные перед их проверкой.