Istio服务网格启用严格mTLS后流量受阻问题求助

核心问题分析 #

你遇到的全网格流量失败，根源在于mTLS策略的作用域不匹配以及无Sidecar工作负载的流量适配缺失，具体原因如下：

1. 你在istio-system命名空间创建的PeerAuthentication仅对该命名空间内的工作负载生效，而非全网格。但全局DestinationRule要求所有客户端发送mTLS流量，导致其他命名空间的服务端无法识别mTLS请求，出现filter_chain_not_found错误。
2. initContainer、未注入Sidecar的Job等工作负载无法生成Istio mTLS证书，直接发送明文请求会被启用严格mTLS的服务端拒绝，引发连接重置。
3. Mesh级别的严格mTLS配置不完整，未覆盖所有命名空间的服务端。

解决方案 #

一、修正PeerAuthentication为Mesh级别 #

创建Mesh范围的PeerAuthentication，确保全网格工作负载强制使用mTLS：

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT
  targetRef:
    kind: Mesh

若部分命名空间需要例外（如允许明文流量），可在对应命名空间创建命名空间级别的PeerAuthentication，设置mode: PERMISSIVE。

二、处理无Sidecar的工作负载 #

1. initContainer流量适配

如果initContainer需要访问网格服务，二选一即可：

• 方式一：允许服务端兼容明文流量：针对目标服务所在命名空间创建宽松模式的PeerAuthentication：

  apiVersion: security.istio.io/v1beta1
  kind: PeerAuthentication
  metadata:
    name: permissive-es
    namespace: <elasticsearch-namespace>
  spec:
    mtls:
      mode: PERMISSIVE
  

• 方式二：手动发送mTLS请求：挂载Istio证书到initContainer，用curl指定证书访问：

  curl --cert /etc/certs/cert-chain.pem --key /etc/certs/key.pem --cacert /etc/certs/root-cert.pem https://elasticsearch.<namespace>.svc.cluster.local:9200
  

2. Job的Sidecar适配

确保Job所在命名空间启用Sidecar自动注入，并添加就绪检查等待Sidecar启动：

apiVersion: batch/v1
kind: Job
metadata:
  name: elasticsearch-license-job
  namespace: <job-namespace>
spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: "true"
    spec:
      containers:
      - name: license-loader
        image: curlimages/curl
        command: ["curl", "-X", "PUT", "https://elasticsearch.<namespace>.svc.cluster.local:9200/_license", "-d", "@/license.json"]
        volumeMounts:
        - name: license-volume
          mountPath: /license.json
          subPath: license.json
      volumes:
      - name: license-volume
        configMap:
          name: elasticsearch-license
      initContainers:
      - name: wait-for-sidecar
        image: busybox:1.28
        command: ['sh', '-c', 'until nc -z localhost 15000; do echo waiting for sidecar; sleep 2; done']

三、解决istio-proxy容器内curl失败问题 #

在istio-proxy容器内访问服务时，需使用Istio证书发送mTLS请求，示例命令：

curl --cert /etc/certs/cert-chain.pem --key /etc/certs/key.pem --cacert /etc/certs/root-cert.pem https://elasticsearch.<namespace>.svc.cluster.local:9200

也可通过sidecar的入站端口转发访问：

curl --header "Host: elasticsearch.<namespace>.svc.cluster.local" https://localhost:15009

四、内部Ingress控制器适配 #

1. 确保Ingress控制器所在命名空间启用Sidecar自动注入；
2. 检查Ingress对应的VirtualService，确保路由指向的后端服务已配置正确的mTLS策略；
3. 若Ingress控制器未注入Sidecar，需为其配置DestinationRule，允许发送明文流量到后端（或为Ingress控制器注入Sidecar）。

常见误区澄清 #

• 不需要为每个服务创建VirtualService：VirtualService仅用于自定义路由规则，mTLS由PeerAuthentication和DestinationRule管控，无特殊路由需求时无需创建。
• 全局DestinationRule已生效：你配置的*.cluster.local DestinationRule已经全局要求客户端发送mTLS流量，问题出在服务端未同步启用严格mTLS。

内容的提问来源于stack exchange，提问作者diDaster