Внешний балансировщик нагрузки Google Cloud TCP и самоподписанный TLS

Можно ли напрямую выставить сервер за балансировщиком нагрузки L4 с помощью общедоступного сертификата?

Этот сервер находится внутри модуля Kubernetes. Перед ним находится служба балансировки нагрузки TCP, которая создает внешний LB L4.

Моя проблема в том, что трафик TLS не достигает контейнера внутри модуля. Так что, если у вас получилось с подобной конфигурацией, мне было бы интересно узнать.


Обновлять

Я не упомянул, что трафик - это GRPC.

Вот что я сделал: у меня есть домен и соответствующий официальный сертификат. Я хочу защитить соединение grpc.

Я пробовал два подхода:

  • с контейнером Google ESP я помещаю сертификат как секрет nginx, передаю его в контейнер, устанавливаю ssl-порт. За ESP в том же модуле стоит мой сервер grpc

В этом случае я получаю такое сообщение на стороне клиента:

D0610 14: 38: 46.246248584 32401 security_handshaker.cc:176] Подтверждение безопасности не удалось: {created: @ 1591792726.246234613, description: Handshake failed, file: ../ deps / grpc / src / core / lib / security / transport / security_handshaker.cc , строка_файла: 291, tsi_code: 10, tsi_error: TSI_PROTOCOL_FAILURE}

Я вижу несколько обменов TLS с WireShark, но без входа в систему, особенно.

  • без ESP я помещаю сертификат на свой сервер GRPC. Здесь сервер GRPC выходит из строя примерно так:

ошибка: 1408F10B: подпрограммы SSL: ssl3_get_record: неправильный номер версии

В документации Google ESP я вижу, что Я должен доказать, что домен принадлежит мне, и загрузить сертификат (но где)?


Обновление 2

На сегодняшний день я не вижу доказательств того, что это возможно.

IMO, основная проблема заключается в том, что L4 имеет IP, соответствующий доменному имени сертификата. Следовательно, у подов нет правильного IP-адреса, чтобы доказать, что они могут использовать сертификат, поэтому их запрос к корням отклонен (у меня нет доказательств этого, так как я не могу получить отладочную информацию от nginx в ESP. Я видел запрос с чистым серверным решением GRPC).


comment
Это определенно возможно. Что ты уже сделал?   -  person suren    schedule 09.06.2020
comment
L4 не разорвет TLS-соединение, он перенаправит его на ваш модуль. Ваша служба должна предоставлять порт 443, а ваш модуль должен разрешать завершение SSL.   -  person Patrick W    schedule 10.06.2020
comment
И ваш модуль должен содержать сертификат TLS (например, с Apache или nginx) для выполнения рукопожатия связи.   -  person guillaume blaquiere    schedule 10.06.2020
comment
@suren спасибо за отзыв, я обновил свой вопрос   -  person unludo    schedule 10.06.2020
comment
Итак, просто чтобы подтвердить, вы хотите предоставить доступ к серверу gRPC, который находится внутри модуля, с завершением TLS на уровне модуля, представленным как LoadBalancer в кластере GKE, это правильно? Кроме того, поделитесь ссылкой, где вы видели, что ESP требует от вас чтобы доказать, что сертификат принадлежит вам, загрузив его. Все ссылки, по которым вы перешли, тоже хороши. Я пытаюсь воспроизвести вашу проблему, и эта информация была бы очень ценной. В противном случае я предоставлю вам пример для gRPC + ESP на GKE, хорошо?   -  person Will R.O.F.    schedule 10.06.2020
comment
@willrof Да, я пробую оба решения (с ESP или без). Я поместил в вопрос ссылку, касающуюся доказательства того, что вы владеете доменом. Мне обязательно будет интересен ваш пример!   -  person unludo    schedule 10.06.2020
comment
Эй, я пытаюсь воспроизвести вашу проблему ... Особенно сложно использовать сертификат домена, не подписанный самостоятельно. Но сейчас я могу вам помочь в одном: - cloud.google. com / endpoints / docs / grpc / verify-domain-name вот как вы подтверждаете свое доменное имя!   -  person Will R.O.F.    schedule 16.06.2020
comment
@willrof Привет, спасибо за попытку. Да, что касается подтверждения домена, я это уже сделал. Дело в том, что теперь https-вызов конечной точки работает (он просто возвращает текст, указывающий, что там нет службы, но он показывает, что сертификат работает). Остается проблема в GRPC с сертификатом, рукопожатия не произойдет. Я подозреваю, что проблема связана с сертификатом или даже с root_cert, поскольку мой сертификат исходит от Ганди.   -  person unludo    schedule 17.06.2020
comment
Другой совет от SSL на ESP: вы должны указать как CN, так и subjectAltName в сертификате вашего сервера. Он должен соответствовать DNS или IP, используемому клиентами для вызова вашей службы. В противном случае квитирование SSL не удастся. Поскольку вы подозреваете о проблеме с сертификатом, было бы очень ценно, если бы вы могли протестировать с другим сертификатом, даже самоподписанным (я обнаружил, что этот метод для создания сертификата с CN и AltSubName очень прост: security.stackexchange.com/a/159537)   -  person Will R.O.F.    schedule 17.06.2020


Ответы (1)


Проблема заключалась в обмене TLS.

Установив сертификат в ESP, он отлично работает с веб-браузером, и сертификат указывается как действительный, тогда как с клиентом GRPC квитирование TLS не выполняется. Помогло добавление дополнительной информации о трассировке.

Проверив свой сертификат (не самоподписанный, а прикрепленный к моему домену), я обнаружил, что с ним поставляется промежуточный сертификат. Я установил его вместе с сертификатом домена (в том же файле crt), и он заработал.

Я не знаю точно, почему он так себя ведет, но, возможно, это связано с тем, что файл root_cert в клиентской библиотеке grpc слишком старый.

Кстати, для сертификата домена нет особых требований относительно CN и subjectAltName для сертификата. Работает и без него. Таким образом, это должно применяться только к самоподписанным сертификатам, как я видел в другом месте.

У меня была другая проблема, которая мешала моей задаче: будьте осторожны и не называйте служебный порт балансировщика нагрузки L4 словом http2 внутри. У меня был некоторый побочный эффект, из-за которого другое развертывание не удалось. Фактически, когда вы используете https, не указывайте http2 в имени.

Во всяком случае, теперь он работает и отвечает на запрос о вознаграждении. Спасибо всем, кто пытался помочь :)

person unludo    schedule 22.06.2020
comment
Обычно сервер должен предоставить полную цепочку сертификатов, но некоторые клиенты TLS (например, все, что основано на Microsoft SecureChannel) по-прежнему принимают сертификат без своей цепочки, если они могут найти промежуточный и корневой сертификат в своем хранилище сертификатов, потому что это такой распространенная ошибка развертывания. Другими словами, ваш браузер лгал, когда сказал, что с сертификатом все в порядке. Другие клиенты TLS (например, все, что основано на OpenSSL) более строги и отклонят это. Легкий способ проверить это - запустить openssl s_client -showcerts -connect $host:$port и поискать ошибки проверки в выходных данных. - person André Caron; 18.11.2020