自动双向 TLS

本任务通过一个简化的工作流，展示如何使用双向 TLS。

借助 Istio 的自动双向 TLS 特性，您只需配置认证策略即可使用双向 TLS，而无需关注目标规则。

Istio 跟踪迁移到 sidecar 的服务端工作负载，并将客户端 sidecar 配置为自动向这些工作负载发送双向 TLS 流量，同时将明文流量发送到没有 sidecar 的工作负载。这使您可以通过最少的配置，逐步在网格中使用双向 TLS。

开始之前

  • 理解 Istio 认证策略 和关于双向 TLS 认证 章节的内容。

  • 安装 Istio 时，配置 global.mtls.enabled 选项为 false，global.mtls.auto 选项为 true。以安装 demo 配置文件为例：

  1. $ istioctl manifest apply --set profile=demo \
  2.   --set values.global.mtls.auto=true \
  3.   --set values.global.mtls.enabled=false

操作指南

安装

本例中，我们部署 httpbin 服务到 full、partial 和 legacy 三个命名空间中，分别代表 Istio 迁移的不同阶段。

命名空间 full 包含已完成 Istio 迁移的所有服务器工作负载。每一个部署都有 Sidecar 注入。

ZipZip

  1. $ kubectl create ns full
  2. $ kubectl apply -f <(istioctl kube-inject -f @samples/httpbin/httpbin.yaml@) -n full
  3. $ kubectl apply -f <(istioctl kube-inject -f @samples/sleep/sleep.yaml@) -n full

命名空间 partial 包含部分迁移到 Istio 的服务器工作负载。只有完成迁移的服务器工作负载（由于已注入 Sidecar）能够使用双向 TLS 流量。

Zip

  1. $ kubectl create ns partial
  2. $ kubectl apply -f <(istioctl kube-inject -f @samples/httpbin/httpbin.yaml@) -n partial
  3. $ cat <<EOF | kubectl apply -n partial -f -
  4. apiVersion: apps/v1
  5. kind: Deployment
  6. metadata:
  7.   name: httpbin-nosidecar
  8. spec:
  9.   replicas: 1
  10.   selector:
  11.     matchLabels:
  12.       app: httpbin
  13.   template:
  14.     metadata:
  15.       labels:
  16.         app: httpbin
  17.         version: nosidecar
  18.     spec:
  19.       containers:
  20.       - image: docker.io/kennethreitz/httpbin
  21.         imagePullPolicy: IfNotPresent
  22.         name: httpbin
  23.         ports:
  24.         - containerPort: 80
  25. EOF

命名空间 legacy 中的工作负载，都没有注入 Sidecar。

ZipZip

  1. $ kubectl create ns legacy
  2. $ kubectl apply -f @samples/httpbin/httpbin.yaml@ -n legacy
  3. $ kubectl apply -f @samples/sleep/sleep.yaml@ -n legacy

接着，我们部署两个 sleep 工作负载，一个有 Sidecar，另一个没有。

ZipZip

  1. $ kubectl apply -f <(istioctl kube-inject -f @samples/sleep/sleep.yaml@) -n full
  2. $ kubectl apply -f @samples/sleep/sleep.yaml@ -n legacy

您可以确认在所有命名空间部署完成。

  1. $ kubectl get pods -n full
  2. $ kubectl get pods -n partial
  3. $ kubectl get pods -n legacy
  4. NAME                      READY   STATUS    RESTARTS   AGE
  5. httpbin-dcd949489-5cndk   2/2     Running   0          39s
  6. sleep-58d6644d44-gb55j    2/2     Running   0          38s
  7. NAME                       READY   STATUS    RESTARTS   AGE
  8. httpbin-6f6fc94fb6-8d62h   1/1     Running   0          10s
  9. httpbin-dcd949489-5fsbs    2/2     Running   0          12s
  10. NAME                       READY   STATUS    RESTARTS   AGE
  11. httpbin-54f5bb4957-lzxlg   1/1     Running   0          6s
  12. sleep-74564b477b-vb6h4     1/1     Running   0          4s

您还需验证系统中是否存在默认的网格验证策略，可以参考下面操作：

  1. $ kubectl get policies.authentication.istio.io --all-namespaces
  2. $ kubectl get meshpolicies -o yaml | grep ' mode'
  3. NAMESPACE      NAME                          AGE
  4. istio-system   grafana-ports-mtls-disabled   2h
  5.         mode: PERMISSIVE

最后但并非最不重要的一点是，确认没有应用于示例服务的目标规则。您可以通过检查已有目标规则的 host: 字段，并确保它们没有匹配我们的示例服务。例如：

  1. $ kubectl get destinationrules.networking.istio.io --all-namespaces -o yaml | grep "host:"
  2.     host: istio-policy.istio-system.svc.cluster.local
  3.     host: istio-telemetry.istio-system.svc.cluster.local

您可通过使用 curl 从命名空间 full、partial 或 legacy 中的任一 sleep Pod 发送 HTTP 请求到 httpbin.full、httpbin.partial 或 httpbin.legacy 以验证安装。所有的请求都应成功返回 HTTP 200 状态码。

例如，这是一个检查 sleep.full 到 httpbin.full 可达性的命令：

  1. $ kubectl exec $(kubectl get pod -l app=sleep -n full -o jsonpath={.items..metadata.name}) -c sleep -n full -- curl http://httpbin.full:8000/headers  -s  -w "response %{http_code}\n" | egrep -o 'URI\=spiffe.*sa/[a-z]*|response.*$'
  2. URI=spiffe://cluster.local/ns/full/sa/sleep
  3. response 200

SPIFFE URI 显示来自 X509 证书的客户端标识，它表明流量是在双向 TLS 中发送的。如果流量为明文，将不会显示客户端证书。

从 PERMISSIVE 模式开始

这里，我们从开启网格服务双向 TLS 的 PERMISSIVE 模式开始。

  • 所有的 httpbin.full 工作负载以及在 httpbin.partial 中使用了 Sidecar 的工作负载都能够使用双向 TLS 和明文流量。

  • 命名空间 httpbin.partial 中没有 Sidecar 的服务和 httpbin.legacy 中的服务都只能使用明文流量。

自动双向 TLS 将客户端和 sleep.full 配置为可将双向 TLS 流量发送到具有 Sidecar 的工作负载，明文流量发送到没有 Sidecar 的工作负载。

您可以通过以下方式验证可达性：

  1. $ for from in "full" "legacy"; do for to in "full" "partial" "legacy"; do echo "sleep.${from} to httpbin.${to}";kubectl exec $(kubectl get pod -l app=sleep -n ${from} -o jsonpath={.items..metadata.name}) -c sleep -n ${from} -- curl http://httpbin.${to}:8000/headers  -s  -w "response code: %{http_code}\n" | egrep -o 'URI\=spiffe.*sa/[a-z]*|response.*$';  echo -n "\n"; done; done
  2. sleep.full to httpbin.full
  3. URI=spiffe://cluster.local/ns/full/sa/sleep
  4. response code: 200
  6. sleep.full to httpbin.partial
  7. URI=spiffe://cluster.local/ns/full/sa/sleep
  8. response code: 200
  10. sleep.full to httpbin.legacy
  11. response code: 200
  13. sleep.legacy to httpbin.full
  14. response code: 200
  16. sleep.legacy to httpbin.partial
  17. response code: 200
  19. sleep.legacy to httpbin.legacy
  20. response code: 200

使用 Sidecar 迁移

无论工作负载是否带有 Sidecar，对 httpbin.partial 的请求都可以到达。Istio 自动将 sleep.full 客户端配置为使用双向 TLS 连接带有 Sidecar 的工作负载。

  1. $ for i in `seq 1 10`; do kubectl exec $(kubectl get pod -l app=sleep -n full -o jsonpath={.items..metadata.name}) -c sleep -nfull  -- curl http://httpbin.partial:8000/headers  -s  -w "response code: %{http_code}\n" | egrep -o 'URI\=spiffe.*sa/[a-z]*|response.*$';  echo -n "\n"; done
  2. URI=spiffe://cluster.local/ns/full/sa/sleep
  3. response code: 200
  5. response code: 200
  7. URI=spiffe://cluster.local/ns/full/sa/sleep
  8. response code: 200
  10. response code: 200
  12. URI=spiffe://cluster.local/ns/full/sa/sleep
  13. response code: 200
  15. URI=spiffe://cluster.local/ns/full/sa/sleep
  16. response code: 200
  18. response code: 200
  20. URI=spiffe://cluster.local/ns/full/sa/sleep
  21. response code: 200
  23. response code: 200
  25. response code: 200

如果不使用自动双向 TLS，您必须跟踪 Sidecar 迁移完成情况，然后显式的配置目标规则，使客户端发送双向 TLS 流量到 httpbin.full。

锁定双向 TLS 为 STRICT 模式

您可配置认证策略为 STRICT，以锁定 httpbin.full 服务仅接收双向 TLS 流量。

  1. $ cat <<EOF | kubectl apply -n full -f -
  2. apiVersion: "authentication.istio.io/v1alpha1"
  3. kind: "Policy"
  4. metadata:
  5.   name: "httpbin"
  6. spec:
  7.   targets:
  8.   - name: httpbin
  9.   peers:
  10.   - mtls: {}
  11. EOF

All httpbin.full workloads and the workload with sidecar for httpbin.partial can only servemutual TLS traffic.

所有 httpbin.full 工作负载和带有 Sidecar 的 httpbin.partial 都只可使用双向 TLS 流量。

现在来自 sleep.legacy 的请求将开始失败，因为其不支持发送双向 TLS 流量。但是客户端 sleep.full 的请求将仍可成功返回 200 状态码，因为它已配置为自动双向 TLS，并且发送双向 TLS 请求。

  1. $ for from in "full" "legacy"; do for to in "full" "partial" "legacy"; do echo "sleep.${from} to httpbin.${to}";kubectl exec $(kubectl get pod -l app=sleep -n ${from} -o jsonpath={.items..metadata.name}) -c sleep -n ${from} -- curl http://httpbin.${to}:8000/headers  -s  -w "response code: %{http_code}\n" | egrep -o 'URI\=spiffe.*sa/[a-z]*|response.*$';  echo -n "\n"; done; done
  2. sleep.full to httpbin.full
  3. URI=spiffe://cluster.local/ns/full/sa/sleep
  4. response code: 200
  6. sleep.full to httpbin.partial
  7. URI=spiffe://cluster.local/ns/full/sa/sleep
  8. response code: 200
  10. sleep.full to httpbin.legacy
  11. response code: 200
  13. sleep.legacy to httpbin.full
  14. response code: 000
  15. command terminated with exit code 56
  17. sleep.legacy to httpbin.partial
  18. response code: 200
  20. sleep.legacy to httpbin.legacy
  21. response code: 200

禁用双向 TLS 以启用明文传输

如果出于某种原因，您希望服务显式地处于明文模式，则可以将身份验证策略配置为明文。

  1. $ cat <<EOF | kubectl apply -n full -f -
  2. apiVersion: "authentication.istio.io/v1alpha1"
  3. kind: "Policy"
  4. metadata:
  5.   name: "httpbin"
  6. spec:
  7.   targets:
  8.   - name: httpbin
  9. EOF

在这种情况下，由于服务处于纯文本模式。Istio 自动配置客户端 Sidecar 发送明文流量以避免错误。

  1. $ for from in "full" "legacy"; do for to in "full" "partial" "legacy"; do echo "sleep.${from} to httpbin.${to}";kubectl exec $(kubectl get pod -l app=sleep -n ${from} -o jsonpath={.items..metadata.name}) -c sleep -n ${from} -- curl http://httpbin.${to}:8000/headers  -s  -w "response code: %{http_code}\n" | egrep -o 'URI\=spiffe.*sa/[a-z]*|response.*$';  echo -n "\n"; done; done
  2. sleep.full to httpbin.full
  3. response code: 200
  5. sleep.full to httpbin.partial
  6. response code: 200
  8. sleep.full to httpbin.legacy
  9. response code: 200
  11. sleep.legacy to httpbin.full
  12. response code: 200
  14. sleep.legacy to httpbin.partial
  15. response code: 200
  17. sleep.legacy to httpbin.legacy
  18. response code: 200

现在，所有流量都可以明文传输。

重写目标规则

为了向后兼容，您仍然可以像以前一样使用目标规则来覆盖 TLS 配置。当目标规则具有显式 TLS 配置时，它将覆盖 Sidecar 客户端的 TLS 配置。

例如，您可以显式的为 httpbin.full 配置目标规则，以显式启用或禁用双向 TLS。

  1. $ cat <<EOF | kubectl apply -n full -f -
  2. apiVersion: "networking.istio.io/v1alpha3"
  3. kind: "DestinationRule"
  4. metadata:
  5.   name: "httpbin-full-mtls"
  6. spec:
  7.   host: httpbin.full.svc.cluster.local
  8.   trafficPolicy:
  9.     tls:
  10.       mode: ISTIO_MUTUAL
  11. EOF

由于在前面的步骤中，我们已经禁用了 httpbin.full 的身份验证策略，以禁用双向TLS，现在应该看到来自 sleep.full 的流量开始失败。

  1. $ for from in "full" "legacy"; do for to in "full" "partial" "legacy"; do echo "sleep.${from} to httpbin.${to}";kubectl exec $(kubectl get pod -l app=sleep -n ${from} -o jsonpath={.items..metadata.name}) -c sleep -n ${from} -- curl http://httpbin.${to}:8000/headers  -s  -w "response code: %{http_code}\n" | egrep -o 'URI\=spiffe.*sa/[a-z]*|response.*$';  echo -n "\n"; done; done
  2. sleep.full to httpbin.full
  3. response code: 503
  5. sleep.full to httpbin.partial
  6. URI=spiffe://cluster.local/ns/full/sa/sleep
  7. response code: 200
  9. sleep.full to httpbin.legacy
  10. response code: 200
  12. sleep.legacy to httpbin.full
  13. response code: 200
  15. sleep.legacy to httpbin.partial
  16. response code: 200
  18. sleep.legacy to httpbin.legacy
  19. response code: 200

清理

  1. $ kubectl delete ns full partial legacy

摘要

自动双向 TLS 配置 Sidecar 客户端默认情况下在 Sidecar 之间发送 TLS 流量。您只需要配置身份验证策略。

如前所述，自动双向 TLS 是网格 Helm 安装选项。您必须重新安装 Istio 才能启用或禁用该功能。当此功能被禁用，如果您已经依靠它来自动加密流量，则流量可以回退到纯明文模式，这可能会影响您的安全状态或中断流量（如果该服务已配置为 STRICT 模式以仅接收双向 TLS 流量）。

当前，自动双向 TLS 还处于 Alpha 阶段，请注意其风险以及 TLS 加密的额外 CPU 成本。

我们正在考虑将此功能设置为默认启用。当您使用自动双向 TLS 时，请考虑通过 GitHub 发送您的反馈或遇到的问题。

相关内容

DNS 证书管理

在 Istio 中配置和管理 DNS 证书。

Istio v1beta1 授权策略概述

Istio v1beta1 授权策略的设计原则、基本概述及迁移操作。

安全管理 Webhook

一种更安全管理 Istio webhook 的方法。

用于隔离和边界保护的多网格部署

将需要隔离的环境部署到单独的网格中，并通过网格联邦启用网格间通信。

APP 身份和访问适配器

使用 Istio 实现零代码改动保护多云 Kubernetes 应用。

Istio 1.2.4 sidecar 镜像漏洞

由于错误的发布操作，出现了错误的 1.2.4 sidecar 镜像。