Как предоставить службы GKE TCP с завершением SSL на границе кластера и аутентификацией сертификата клиента

Я ищу общий способ предоставить внешнему миру несколько служб GKE TCP. Мне нужен SSL, который завершается на границе кластера. Я бы также предпочел аутентификацию на основе сертификата клиента, если это возможно.

Мой текущий вариант использования - доступ к службам PostgreSQL, развернутым в GKE, из частных центров обработки данных (и только оттуда). Но в основном меня интересует решение, которое работает для любой службы на основе TCP без встроенного SSL и аутентификации.

Один из вариантов - развернуть nginx в качестве обратного прокси для службы TCP, открыть nginx с помощью службы типа LoadBalancer (L4, балансировщик сетевой нагрузки) и настроить nginx с SSL и проверкой сертификата клиента.

Есть ли лучший способ добиться этого с помощью GKE?


kubernetes google-cloud-platform google-kubernetes-engine nginx gke-networking
person Laurentiu Soica    schedule 11.10.2020    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Насколько мне известно, не существует встроенного в GKE способа добиться именно того, что вам нужно.

Если бы это касалось только трафика на основе HTTP, вы могли бы просто использовать GKE Ingress для Балансировка нагрузки HTTP (S), но с учетом:

Но в основном меня интересует решение, которое работает для любой службы на основе TCP без встроенного SSL и аутентификации.

это не ваш вариант использования.

Таким образом, вы можете остаться с тем, что вы уже настроили, поскольку это кажется хорошо работающим, или в качестве альтернативы вы можете использовать:

  1. ✅ nginx ingress, который в отличие от GKE ingress может открывать для внешнего мира не только Трафик на основе HTTP / HTTPS, но также может проксировать TCP-соединения, поступающие на произвольные порты.

  2. ✅ Вы можете использовать прокси завершения TLS в качестве дополнительного элемента (что-то вроде этот или этот ) за внешним балансировщиком сетевой нагрузки TCP / UDP. Поскольку это не прокси, а сквозной LB, он не может обеспечить завершение SSL и сможет передавать зашифрованный TCP-трафик на бэкэнд Pod только там, где это необходимо. обрабатываться с помощью вышеупомянутой коляски.

  3. ❌ Из собственных решений балансировки нагрузки GCP, представленных в эта таблица только SSL-прокси может показаться полезным на первый взгляд, поскольку он может обрабатывать TCP-трафик с разгрузкой SSL, однако ❗ он поддерживает только ограниченный набор хорошо известных TCP-портов и насколько я поймите, вам нужно иметь возможность открывать произвольные TCP-порты, поэтому это вам не очень поможет:

Поддержка балансировки нагрузки прокси-сервера SSL для следующих портов: 25, 43, 110, 143, 195, 443, 465, 587, 700, 993, 995, 1883, 3389, 5222, 5432, 5671, 5672 , 5900, 5901, 6379, 8085, 8099, 9092, 9200 и 9300. При использовании SSL-сертификатов, управляемых Google, с балансировкой нагрузки прокси-сервера SSL, интерфейсный порт для трафика должен быть 443, чтобы можно было использовать SSL-сертификаты, управляемые Google. подготовлен и обновлен.

person mario    schedule 22.10.2020