Egress TLS Origination

    假设有一个遗留应用正在使用 HTTP 和外部服务进行通信。而运行该应用的组织却收到了一个新的需求,该需求要求必须对所有外部的流量进行加密。 此时,使用 Istio 便可通过修改配置实现此需求,而无需更改应用中的任何代码。 该应用可以发送未加密的 HTTP 请求,然后 Istio 将为应用加密请求。

    从应用源头发送未加密的 HTTP 请求并让 Istio 执行 TSL 升级的另一个好处是可以产生更好的遥测并为未加密的请求提供更多的路由控制。

    开始之前

    • 根据安装指南中的说明部署 Istio。

    • 启动 示例,该示例将用作外部调用的测试源。

      如果启用了 Sidecar 的自动注入功能,运行以下命令部署 应用:

      否则在部署 sleep 应用之前,您必须手动注入 Sidecar。

      Zip

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

      实际上任何可以 execcurl 的 Pod 都可以用来完成这一任务。

    • 创建一个环境变量来保存用于将请求发送到外部服务的 pod 的名称。 如果您使用 示例,请运行:

      1. $ export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})

    首先,使用与 任务中的相同的技术,配置对外部服务 edition.cnn.com 的访问。 但这一次我们将使用单个 ServiceEntry 来启用对服务的 HTTP 和 HTTPS 访问。

    1. 创建一个 ServiceEntry 启用对 edition.cnn.com 的访问:

      1. $ kubectl apply -f - <<EOF
      2. apiVersion: networking.istio.io/v1alpha3
      3. kind: ServiceEntry
      4. metadata:
      5. name: edition-cnn-com
      6. spec:
      7. hosts:
      8. - edition.cnn.com
      9. ports:
      10. - number: 80
      11. name: http-port
      12. protocol: HTTP
      13. - number: 443
      14. name: https-port
      15. protocol: HTTPS
      16. resolution: DNS
      17. EOF
    2. 向外部的 HTTP 服务发送请求:

      1. $ kubectl exec "${SOURCE_POD}" -c sleep -- curl -sSL -o /dev/null -D - http://edition.cnn.com/politics
      2. HTTP/1.1 301 Moved Permanently
      3. ...
      4. location: https://edition.cnn.com/politics
      5. ...
      6. HTTP/2 200

    请注意 curl-L 标志,该标志指示 curl 将遵循重定向。 在这种情况下,服务器将对到 http://edition.cnn.com/politics 的 HTTP 请求返回重定向响应 (301 Moved Permanently)。 而重定向响应将指示客户端使用 HTTPS 向 https://edition.cnn.com/politics 重新发送请求。 对于第二个请求,服务器则返回了请求的内容和 200 OK 状态码。

    尽管 curl 命令简明地处理了重定向,但是这里有两个问题。 第一个问题是请求冗余,它使获取 http://edition.cnn.com/politics 内容的延迟加倍。 第二个问题是 URL 中的路径(在本例中为 politics )被以明文的形式发送。 如果有人嗅探您的应用与 edition.cnn.com 之间的通信,他将会知晓该应用获取了此网站中哪些特定的内容。 而出于隐私的原因,您可能希望阻止这些内容被披露。

    通过配置 Istio 执行 TLS 发起,则可以解决这两个问题。

    用于 egress 流量的 TLS 发起

    1. 重新定义上一节的 ServiceEntryVirtualService 以重写 HTTP 请求端口,并添加一个 以执行 TLS 发起。

      1. $ kubectl apply -f - <<EOF
      2. apiVersion: networking.istio.io/v1alpha3
      3. kind: ServiceEntry
      4. metadata:
      5. name: edition-cnn-com
      6. spec:
      7. hosts:
      8. - edition.cnn.com
      9. ports:
      10. - number: 80
      11. name: http-port
      12. protocol: HTTP
      13. targetPort: 443
      14. - number: 443
      15. name: https-port
      16. protocol: HTTPS
      17. resolution: DNS
      18. ---
      19. apiVersion: networking.istio.io/v1alpha3
      20. kind: DestinationRule
      21. metadata:
      22. name: edition-cnn-com
      23. spec:
      24. host: edition.cnn.com
      25. trafficPolicy:
      26. portLevelSettings:
      27. - port:
      28. number: 80
      29. tls:
      30. mode: SIMPLE # initiates HTTPS when accessing edition.cnn.com
      31. EOF

      上面的 DestinationRule 将对端口80和 ServiceEntry 上的HTTP请求执行TLS发起。然后将端口 80 上的请求重定向到目标端口 443。

    2. 如上一节一样,向 http://edition.cnn.com/politics 发送 HTTP 请求:

      这次将会收到唯一的 200 OK 响应。 因为 Istio 为 curl 执行了 TSL 发起,原始的 HTTP 被升级为 HTTPS 并转发到 edition.cnn.com。 服务器直接返回内容而无需重定向。 这消除了客户端与服务器之间的请求冗余,使网格保持加密状态,隐藏了您的应用获取 edition.cnn.compolitics 的事实。

      请注意,您使用了一些与上一节相同的命令。 您可以通过配置 Istio,使以编程方式访问外部服务的应用无需更改任何代码即可获得 TLS 发起的好处。

    3. 请注意,使用 HTTPS 访问外部服务的应用程序将继续像以前一样工作:

      1. $ kubectl exec "${SOURCE_POD}" -c sleep -- curl -sSL -o /dev/null -D - https://edition.cnn.com/politics
      2. HTTP/2 200
      3. ...

    由于应用容器与本地 Host 上的 Sidecar 代理之间的流量仍未加密,能够渗透到您应用 Node 的攻击者仍然可以看到未加密 Node 本地网络上的通信。 在某些环境中,严格的安全性要求可能规定所有流量都必须加密,即使在 Node 的本地网络上也是如此。 此时,使用在此示例中描述的 TLS 发起是不能满足要求的,应用应仅使用 HTTPS(TLS)而不是 HTTP。

    还要注意,即使应用发起的是 HTTPS 请求,攻击者也可能会通过检查 知道客户端正在对 edition.cnn.com 发送请求。 SNI 字段在 TLS 握手过程中以未加密的形式发送。 使用 HTTPS 可以防止攻击者知道客户端访问了哪些特点的内容,但并不能阻止攻击者得知客户端访问了 edition.cnn.com 站点。

    1. 移除您创建的 Istio 配置项:

      1. $ kubectl delete serviceentry edition-cnn-com
      2. $ kubectl delete destinationrule edition-cnn-com

    出口流量的双向 TLS 发起

    本节介绍如何配置 sidecar 为外部服务执行 TLS 发起,这次使用需要双向 TLS 的服务。 此示例涉及许多内容,需要先执行以下前置操作:

    1. 生成客户端和服务器证书
    2. 部署支持双向 TLS 协议的外部服务
    3. 将客户端(sleep Pod)配置为使用在步骤 1 中创建的凭据

    生成客户端证书、服务器证书、客户端密钥和服务器密钥

    按照 Egress Gateway TLS 发起任务中的进行操作。

    按照 Egress Gateway TLS 发起任务中的进行操作。

    配置客户端——sleep Pod

    1. 创建 Kubernetes 来保存客户端的证书:

      1. --from-file=tls.crt=client.example.com.crt --from-file=ca.crt=example.com.crt

      必须在部署客户端 Pod 的统一命名空间中创建密钥,本例为 default

    2. 创建必需的 RBAC 以确保在上述步骤中创建的密钥对客户端 Pod 是可访问的,在本例中是 sleep

      1. $ kubectl create role client-credential-role --resource=secret --verb=list
      2. $ kubectl create rolebinding client-credential-role-binding --role=client-credential-role --serviceaccount=default:sleep
    1. 添加一个 DestinationRule 以执行双向 TLS 发起

      1. $ kubectl apply -f - <<EOF
      2. apiVersion: networking.istio.io/v1alpha3
      3. kind: DestinationRule
      4. metadata:
      5. name: originate-mtls-for-nginx
      6. spec:
      7. workloadSelector:
      8. matchLabels:
      9. app: sleep
      10. host: my-nginx.mesh-external.svc.cluster.local
      11. trafficPolicy:
      12. loadBalancer:
      13. simple: ROUND_ROBIN
      14. portLevelSettings:
      15. - port:
      16. number: 443
      17. tls:
      18. mode: MUTUAL
      19. credentialName: client-credential # this must match the secret created earlier to hold client certs, and works only when DR has a workloadSelector
      20. sni: my-nginx.mesh-external.svc.cluster.local # this is optional
      21. EOF
    2. 发送一个 HTTP 请求到 http://my-nginx.mesh-external.svc.cluster.local

    3. 检查 sleep Pod 的日志中是否有与我们的请求相对应的行。

      1. $ kubectl logs -l app=sleep -c istio-proxy | grep 'my-nginx.mesh-external.svc.cluster.local'

      You should see a line similar to the following:

      1. [2022-05-19T10:01:06.795Z] "GET / HTTP/1.1" 200 - via_upstream - "-" 0 615 1 0 "-" "curl/7.83.1-DEV" "96e8d8a7-92ce-9939-aa47-9f5f530a69fb" "my-nginx.mesh-external.svc.cluster.local:443" "10.107.176.65:443"

    清理双向 TLS 发起配置

    1. 移除创建的 Kubernetes 资源:

      1. $ kubectl delete secret nginx-server-certs nginx-ca-certs -n mesh-external
      2. $ kubectl delete secret client-credential
      3. $ kubectl delete configmap nginx-configmap -n mesh-external
      4. $ kubectl delete service my-nginx -n mesh-external
      5. $ kubectl delete deployment my-nginx -n mesh-external
      6. $ kubectl delete namespace mesh-external
      7. $ kubectl delete serviceentry originate-mtls-for-nginx
      8. $ kubectl delete destinationrule originate-mtls-for-nginx
    2. 删除证书和私钥:

      1. $ rm example.com.crt example.com.key my-nginx.mesh-external.svc.cluster.local.crt my-nginx.mesh-external.svc.cluster.local.key my-nginx.mesh-external.svc.cluster.local.csr client.example.com.crt client.example.com.csr client.example.com.key
    3. 删除本示例中用过的和生成的那些配置文件:

      1. $ rm ./nginx.conf

    删除 sleep 服务和部署: