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

Question

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

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

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

我想做什么：

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

我不想做的事：

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

几周以来，我一直在努力让它工作，但没有成功。社区的任何帮助将不胜感激。

Answer 1

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

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

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

查看此处了解有关服务之间的 mtls 如何工作的更多信息。

Istio 中的双向 TLS

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

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

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

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

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

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

NGINX

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

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

Answer 由@stono 提供。

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

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

注释： nginx.ingress.kubernetes.io/service-upstream：“真” 这样做是为了确保 nginx 不会将上游地址解析为 ip，并维护正确的 Host 标头，sidecar 使用该标头来路由到您的目的地。

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

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

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