双向 TLS 迁移

    针对多服务跨网络通信的应用场景,通常希望逐步将所有服务迁移到 Istio 网格中。如此一来,在迁移过程中,将出现只有部分服务注入了 Envoy sidecar 的情况。对于一个已注入 sidecar 的服务而言,一旦开启服务的双向 TLS 通信模式,那么传统客户端(即:没有 Envoy 的客户端)将无法与之通信,因为这些客户端没有注入 Envoy sidecar 和客户端证书。为了解决这个问题,Istio 认证策略提供了一种 “PERMISSIVE” 模式。当启用 “PERMISSIVE” 模式时,服务可以同时接收 HTTP 和双向 TLS 请求。

    这样,便可以将 Istio 服务的通信模式配置为双向 TLS,与此同时,不干扰其与传统服务之间的通信。此外,可以使用 Grafana dashboard 检查哪些服务仍然向 “PERMISSIVE” 模式的服务发送明文请求,然后选择在这些服务迁移结束后关闭目标服务的 “PERMISSIVE” 模式,将其锁定为只接收双向 TLS 请求。

    • 理解 Istio 以及相关的双向 TLS 认证概念。

    • 准备一个 Kubernetes 集群并部署好 Istio,不要开启全局双向 TLS (如:可以使用中提供的 demo 配置 profile,或者将安装选项 设置为 false)。

    • demo 准备

      • 创建如下命名空间并在其中都部署上 httpbin 和 ,注入 sidecar。

        • foo
        • bar
        • legacy

      ZipZipZip

    • (使用 curl 命令)从每个 sleep pod (命名空间为 foobarlegacy)分别向 httpbin.foo 发送 http 请求。所有请求都应成功响应,返回 HTTP code 200。

      1. sleep.foo to httpbin.foo: 200
      2. sleep.bar to httpbin.foo: 200
      3. sleep.legacy to httpbin.foo: 200
    • 验证没有在系统中设置认证策略或目标规则(控制面板除外):

      1. $ kubectl get policies.authentication.istio.io --all-namespaces
      2. NAMESPACE NAME AGE
      3. istio-system grafana-ports-mtls-disabled 3m

    设置 DestinationRule,配置 Istio 服务发送双向 TLS 请求。

    1. $ cat <<EOF | kubectl apply -n foo -f -
    2. apiVersion: "networking.istio.io/v1alpha3"
    3. metadata:
    4. name: "example-httpbin-istio-client-mtls"
    5. spec:
    6. trafficPolicy:
    7. tls:
    8. mode: ISTIO_MUTUAL
    9. EOF

    sleep.foosleep.bar 开始向 httpbin.foo 发送双向 TLS 请求。因为 sleep.legacy 没有注入 sidecar,DestinationRule 不会对其起作用,所以 sleep.legacy 仍然向 httpbin.foo 发送明文请求。

    现在,我们确认一下,所有发送至 httpbin.foo 的请求仍会响应成功。

    1. $ for from in "foo" "bar" "legacy"; do kubectl exec $(kubectl get pod -l app=sleep -n ${from} -o jsonpath={.items..metadata.name}) -c sleep -n ${from} -- curl http://httpbin.foo:8000/ip -s -o /dev/null -w "sleep.${from} to httpbin.foo: %{http_code}\n"; done
    2. sleep.bar to httpbin.foo: 200
    3. sleep.legacy to httpbin.foo: 200

    当所有客户端服务都成功迁移至 Istio 之后,注入 Envoy sidecar,便可以锁定 httpbin.foo 只接收双向 TLS 请求。

    此时,源自 sleep.legacy 的请求将响应失败。

    1. $ for from in "foo" "bar" "legacy"; do kubectl exec $(kubectl get pod -l app=sleep -n ${from} -o jsonpath={.items..metadata.name}) -c sleep -n ${from} -- curl http://httpbin.foo:8000/ip -s -o /dev/null -w "sleep.${from} to httpbin.foo: %{http_code}\n"; done
    2. sleep.foo to httpbin.foo: 200
    3. sleep.bar to httpbin.foo: 200
    4. sleep.legacy to httpbin.foo: 503

    如果你安装 Istio 时带有参数 values.global.proxy.privileged=true,那么你可以使用 tcpdump 来验证流量是否被加密。

    1. $ kubectl exec -nfoo "$(kubectl get pod -nfoo -lapp=httpbin -ojsonpath={.items..metadata.name})" -c istio-proxy -it -- sudo tcpdump dst port 80 -A
    2. listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

    当分别从 sleep.legacysleep.foo 发送请求时,您将在输出中看到纯文本和加密文本。

    若无法将所有服务迁移至 Istio (注入 Envoy sidecar),则必须开启 模式。 然而,开启 PERMISSIVE 模式时,系统默认不对明文请求进行认证或授权检查。 推荐使用 来为不同的请求路径配置不同的授权策略。

    清除所有资源。