kubernetes - Istio | 不使用 Istio 入口网关的 TLS 双向认证

Question

我想在 kubernetes 集群中运行的不同服务之间实现 TLS 相互身份验证，我发现 Istio 是一个很好的解决方案，无需对代码进行任何更改即可实现这一目标。

我正在尝试使用 Istio 边车注入在集群内运行的服务之间进行 TLS 相互身份验证。

• 外部流量通过 nginx 入口控制器进入网格。我们希望继续使用它而不是 Istio 入口控制器（我们希望尽可能少地进行更改）。
• 当 Istio Sidecar 注入被禁用时，这些服务能够正确地相互通信。但是，一旦我在应用程序的命名空间中启用了 sidecar，应用程序就不再能够为请求提供服务（我猜传入的请求会被 envoy sidecar 代理丢弃）。

我想做的事：

• 在 namespace-2（nginx 入口控制器，服务 1 和服务 2）上启用 istio sidecar 代理注入，以便所有服务通过 TLS 相互身份验证相互通信。

我不想做的事情：

• 在 nginx 入口控制器上启用 istio sidecar 代理注入（我不想对其进行任何更改，因为它用作多个其他工作负载的前端）。

几个星期以来，我一直在努力让它工作，但没有运气。来自社区的任何帮助将不胜感激。

标签： kubernetesgoogle-cloud-platformgoogle-kubernetes-engineistioenvoyproxy

Answer 1

我的目标是至少在 service-1 和 service-2 之间启用 TLS 相互身份验证

AFAIK 如果您在 namespace-2 中启用了注入，那么这里的服务已经启用了 mTLS。从 istio 1.5 版本开始默认启用。有关于此的相关文档。

现在默认启用自动双向 TLS。Sidecar 之间的流量自动配置为双向 TLS。如果您担心加密开销，您可以通过在安装期间添加选项 -- set values.global.mtls.auto=false 来明确禁用此功能。有关更多详细信息，请参阅自动双向 TLS。

在这里查看有关服务之间的 mtls 如何工作的更多信息。

Istio 中的双向 TLS

Istio 提供双向 TLS 作为服务到服务身份验证的解决方案。

Istio 使用 sidecar 模式，这意味着每个应用程序容器都有一个 sidecar Envoy 代理容器在其旁边运行在同一个 pod 中。

• 当服务接收或发送网络流量时，流量总是首先通过 Envoy 代理。

• 当在两个服务之间启用 mTLS 时，客户端和服务器端 Envoy 代理在发送请求之前会验证彼此的身份。

• 如果验证成功，则客户端代理对流量进行加密，并将其发送到服务器端代理。

• 服务器端代理解密流量并将其在本地转发到实际的目标服务。

NGINX

但问题是，来自网格外部的流量在入口资源处被终止。namespace-2 中的 nginx 反向代理看不到来电。

我看到github上有类似的问题，值得尝试。

@stono提供的答案。

嘿，这不是 istio 的问题，让 nginx 与 istio 一起工作有点困难。问题是因为基本上 nginx 正在向已从您的主机名 foo-bar 解析的 IP 发出出站请求。这不起作用，因为特使不知道集群 ip 属于什么，所以它失败了。

我建议使用 ingress-nginx kubernetes 项目，然后在 Ingress 配置中使用以下值：

注释： nginx.ingress.kubernetes.io/service-upstream: "true" 这样做是为了确保 nginx 不会将上游地址解析为 ip，并维护 Sidecar 用于路由到的正确 Host 标头你的目的地。

我推荐使用这个项目，因为我将它与 Istio 一起用于 240 多个服务部署。

如果你不使用ingress-nginx，我认为你可以设置proxy_ssl_server_name；或者您可以尝试的另一件事是将出站请求上的 Host 标头强制设置为服务的内部 fqdn，以便：

proxy_set_header 主机 foo-bar；希望这会有所帮助，但正如我所说，这是 nginx 配置而不是 istio 问题。