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

Question

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

外部流量通过 nginx 入口 Controller 进入网格。我们希望继续使用它而不是 Istio 入口 Controller (我们希望尽可能少地进行更改)。

当 Istio Sidecar 注入(inject)被禁用时，这些服务能够正确地相互通信。但是，一旦我在应用程序的命名空间中启用了 sidecar，应用程序就不再能够为请求提供服务(我猜传入的请求会被 envoy sidecar 代理丢弃)。

我想做的事:

在 namespace-2(nginx 入口 Controller ，服务 1 和服务 2)上启用 istio sidecar 代理注入(inject)，以便所有服务通过 TLS 相互身份验证相互通信。

我不想做的事情:

在 nginx 入口 Controller 上启用 istio sidecar 代理注入(inject)(我不想对其进行任何更改，因为它用作多个其他工作负载的前端)。

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

Answer 1

my goal is to atleast enable TLS mutual auth between service-1 and service-2

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

Automatic mutual TLS is now enabled by default. Traffic between sidecars is automatically configured as mutual TLS. You can disable this explicitly if you worry about the encryption overhead by adding the option -- set values.global.mtls.auto=false during install. For more details, refer to automatic mutual TLS.

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

Istio offers mutual TLS as a solution for service-to-service authentication.

Istio uses the sidecar pattern, meaning that each application container has a sidecar Envoy proxy container running beside it in the same pod.

• When a service receives or sends network traffic, the traffic always goes through the Envoy proxies first.

• When mTLS is enabled between two services, the client side and server side Envoy proxies verify each other’s identities before sending requests.

• If the verification is successful, then the client-side proxy encrypts the traffic, and sends it to the server-side proxy.

• The server-side proxy decrypts the traffic and forwards it locally to the actual destination service.

NGINX

But the problem is, the traffic from outside the mesh is getting terminated at the ingress resource. The nginx reverse proxy in namespace-2 does not see the incoming calls.

我看到 github 上有类似的问题关于这一点，值得一试。
Answer由@stono 提供。

Hey, This is not an istio issue, getting nginx to work with istio is a little bit difficult. The issue is because fundamentally nginx is making an outbound request to an ip that is has resolved from your hostname foo-bar. This won't work as envoy doesn't know what cluster ip belongs to, so it fails.

I'd suggest using the ingress-nginx kubernetes project and in turn using the following value in your Ingress configuration:

annotations: nginx.ingress.kubernetes.io/service-upstream: "true" What this does is ensure that nginx doesn't resolve the upstream address to an ip, and maintains the correct Host header which the sidecar uses in order to route to your destination.

I recommend using this project because I use it, with Istio, with a 240 odd service deployment.

If you're not using ingress-nginx, I think you can set proxy_ssl_server_name on; or another thing you could try is forcefully setting the Host header on the outbound request to the internal fqdn of the service so:

proxy_set_header Host foo-bar; Hope this helps but as I say, it's an nginx configuration rather than an istio problem.