双向 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. $ 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: 200
    • 验证没有在系统中设置认证策略或目标规则(控制面板除外):

      1. NAMESPACE NAME AGE
      2. istio-system grafana-ports-mtls-disabled 3m
      1. $ kubectl get destinationrule --all-namespaces
      2. NAMESPACE NAME HOST AGE
      3. istio-system istio-multicluster-destinationrule *.global 35s
      4. istio-system istio-policy istio-policy.istio-system.svc.cluster.local 35s
      5. istio-system istio-telemetry istio-telemetry.istio-system.svc.cluster.local 33s

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

    sleep.foosleep.bar 开始向 httpbin.foo 发送双向 TLS 请求。因为 没有注入 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.foo to httpbin.foo: 200
    3. sleep.bar to httpbin.foo: 200
    4. sleep.legacy to httpbin.foo: 200

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

    1. $ cat <<EOF | kubectl apply -n foo -f -
    2. apiVersion: "security.istio.io/v1beta1"
    3. kind: "PeerAuthentication"
    4. metadata:
    5. name: "default"
    6. spec:
    7. mtls:
    8. mode: STRICT

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

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

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

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

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

    1. $ kubectl apply -n istio-system -f - <<EOF
    2. apiVersion: security.istio.io/v1beta1
    3. kind: PeerAuthentication
    4. metadata:
    5. name: "default"
    6. spec:
    7. mtls:
    8. mode: STRICT
    9. EOF

    现在,foobar 命名空间都强制执行仅双向 TLS 流量,因此您应该会看到来自 sleep.legacy 的请求 访问两个命名空间的服务都失败了。

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