Google Cloud TCP 外部负载平衡器和 TLS 未自签名

unl*_*udo 6 ssl load-balancing google-cloud-platform google-kubernetes-engine gke-networking

是否可以使用公共证书直接在 L4 负载均衡器后面公开服务器?

该服务器位于 Kubernetes pod 内。它前面有一个 TCP 负载均衡器服务,用于创建外部 L4 LB。

我的问题是 TLS 流量无法到达 pod 内的容器。因此,如果您使用类似的配置成功,我将有兴趣了解。


更新

我没有提到流量是GRPC。

这是我所做的:我有一个域和一个相应的官方证书。我想保护 grpc 连接。

我尝试了两种方法:

  • 使用 google ESP 容器,我将证书作为 nginx 机密,将其传递给容器,设置 ssl 端口。在同一个 Pod 中的 ESP 后面,我有我的 grpc 服务器

在这种情况下,我在客户端收到这样的消息:

D0610 14:38:46.246248584 32401 security_handshaker.cc:176] 安全握手失败:{"created":"@1591792726.246234613","description":"握手失败","file"/:"。 core/lib/security/transport/security_handshaker.cc","file_line":291,"tsi_code":10,"tsi_error":"TSI_PROTOCOL_FAILURE"}

我看到一些与wireshark的TLS交换,但没有登录esp。

  • 没有 ESP,我将证书放在我的 GRPC 服务器中。在那里 GRPC 服务器失败,如下所示:

错误:1408F10B:SSL 例程:ssl3_get_record:版本号错误

google ESP 文档中,我看到我必须证明域属于我并上传证书(但在哪里)?


更新 2

截至今天,我没有看到任何证据表明这是可行的。

IMO,主要问题是L4有对应证书域名的IP。因此,pod 没有正确的 IP 来证明他们可以使用证书,因此他们对根的请求被拒绝(我没有证据,因为我无法从 ESP 中的 nginx 获取调试信息。我看到了一个使用纯 GRPC 服务器解决方案请求)。

unl*_*udo 2

问题出在 TLS 交换中。

通过在 ESP 中安装证书,它可以在 Web 浏览器中正常工作,并且证书显示为有效,而对于 GRPC 客户端,TLS 握手会失败。添加额外的跟踪信息有帮助。

通过检查我的证书(不是自签名的,而是附加到我的域),我发现它附带了一个中间证书。我将它与域证书(在同一个 crt 文件中)一起安装,然后它就工作了。

我不知道为什么它会这样,但也许是因为 grpc 客户端库中的 root_cert 文件太旧了。

顺便说一下,对于域证书,对于证书的 CN 和 subjectAltName 没有具体要求。没有它它也能工作。因此,它必须仅适用于我在其他地方看到的自签名证书。

我还有另一个问题干扰了我的任务:小心不要将 L4 负载均衡器的服务端口命名为“http2”。我有一些副作用,导致另一个部署因此失败。事实上,当你做https时,不要把http2放在名称中。

无论如何,它现在正在工作并响应赏金请求。感谢所有试图提供帮助的人:)