HTTP 出站流量的监控和访问策略

虽然 Istio 的主要关注点是管理服务网格内微服务之间的流量，但 Istio 也可以管理入口（从外部进入网格）和出口（从网格向外）流量。Istio 可以统一地执行网格内部、入口和出口流量的访问策略并聚合遥测数据。

在本博文中，我们将展示如何使用 Istio 对 HTTP 出站流量应用监控和访问策略。

用例

假设一个组织运行处理来自 cnn.com 内容的应用程序。这些应用程序被分解成部署在 Istio 服务网格中的微服务。应用程序访问 cnn.com 上各个主题的页面：edition.cnn.com/politics、edition.cnn.com/sport 和 edition.cnn.com/health。该组织配置 Istio 以允许访问 edition.cnn.com，并且一切正常。但是，在某个时间点，该组织决定禁止政治。实际上，这意味着阻止对 edition.cnn.com/politics 的访问，并且仅允许访问 edition.cnn.com/sport 和 edition.cnn.com/health。该组织将根据具体情况，授予各个应用程序和特定用户访问 edition.cnn.com/politics 的权限。

为了实现这一目标，该组织的操作人员会监控对外部服务的访问，并分析 Istio 日志以验证没有未经授权的请求发送到 edition.cnn.com/politics。他们还会配置 Istio 以自动阻止对 edition.cnn.com/politics 的访问。

该组织决心防止对新策略的任何篡改。它决定实施一些机制，以防止任何恶意应用程序访问被禁止的主题。

相关任务和示例

• 在控制出站流量任务中演示了网格内的应用程序如何访问外部（Kubernetes 集群外部）HTTP 和 HTTPS 服务。
• 在配置出站网关示例中描述了如何配置 Istio 以通过称为出站网关的专用网关服务引导出站流量。
• 在带有 TLS 发起的出站网关示例中演示了如何在引导流量通过出站网关的同时，允许应用程序向需要 HTTPS 的外部服务器发送 HTTP 请求。
• 在使用 Grafana 可视化指标中描述了 Istio 仪表板以监控网格流量。
• 在基本访问控制任务中展示了如何控制对网格内服务的访问。
• 在拒绝和白/黑名单任务中展示了如何使用黑名单或白名单检查器配置访问策略。

与上述可观察性和安全任务相反，本博文描述了 Istio 的监控和访问策略，这些策略专门应用于出站流量。

开始之前

按照带有 TLS 发起的出站网关示例中的步骤操作，**启用双向 TLS 身份验证**，但不要执行清理步骤。完成该示例后，您可以从安装了 curl 的网格内容器访问 edition.cnn.com/politics。本博文假设 SOURCE_POD 环境变量包含源 Pod 的名称，并且容器的名称为 sleep。

配置监控和访问策略

由于您希望以安全的方式完成任务，因此应按照带有 TLS 发起的出站网关任务中所述，通过出站网关引导出站流量。这里的安全方式意味着您希望防止恶意应用程序绕过 Istio 监控和策略执行。

根据我们的场景，该组织执行了开始之前部分中的说明，启用了对 edition.cnn.com 的 HTTP 流量，并配置了该流量以通过出站网关。出站网关对 edition.cnn.com 执行 TLS 发起，因此流量以加密方式离开网格。此时，该组织已准备好配置 Istio 以监控和应用对 edition.cnn.com 流量的访问策略。

日志记录

配置 Istio 以记录对 *.cnn.com 的访问。您创建了一个 logentry 和两个stdio handlers，一个用于记录被禁止的访问（错误日志级别），另一个用于记录对 *.cnn.com 的所有访问（信息日志级别）。然后，您创建 rules 以将 logentry 实例定向到您的 handlers。一个规则将对 *.cnn.com/politics 的访问定向到用于记录被禁止访问的 handler，另一个规则将日志条目定向到将每个对 *.cnn.com 的访问作为信息日志条目输出的 handler。要了解 Istio logentries、rules 和 handlers，请参阅Istio 适配器模型。下面显示了一个包含相关实体及其之间依赖关系的图表

1. 创建 logentry、rules 和 handlers。请注意，您在规则中将 context.reporter.uid 指定为 kubernetes://istio-egressgateway，以仅获取来自出站网关的日志。

   $ cat <<EOF | kubectl apply -f -
   # Log entry for egress access
   apiVersion: "config.istio.io/v1alpha2"
   kind: logentry
   metadata:
     name: egress-access
     namespace: istio-system
   spec:
     severity: '"info"'
     timestamp: request.time
     variables:
       destination: request.host | "unknown"
       path: request.path | "unknown"
       responseCode: response.code | 0
       responseSize: response.size | 0
       reporterUID: context.reporter.uid | "unknown"
       sourcePrincipal: source.principal | "unknown"
     monitored_resource_type: '"UNSPECIFIED"'
   ---
   # Handler for error egress access entries
   apiVersion: "config.istio.io/v1alpha2"
   kind: stdio
   metadata:
     name: egress-error-logger
     namespace: istio-system
   spec:
    severity_levels:
      info: 2 # output log level as error
    outputAsJson: true
   ---
   # Rule to handle access to *.cnn.com/politics
   apiVersion: "config.istio.io/v1alpha2"
   kind: rule
   metadata:
     name: handle-politics
     namespace: istio-system
   spec:
     match: request.host.endsWith("cnn.com") && request.path.startsWith("/politics") && context.reporter.uid.startsWith("kubernetes://istio-egressgateway")
     actions:
     - handler: egress-error-logger.stdio
       instances:
       - egress-access.logentry
   ---
   # Handler for info egress access entries
   apiVersion: "config.istio.io/v1alpha2"
   kind: stdio
   metadata:
     name: egress-access-logger
     namespace: istio-system
   spec:
     severity_levels:
       info: 0 # output log level as info
     outputAsJson: true
   ---
   # Rule to handle access to *.cnn.com
   apiVersion: "config.istio.io/v1alpha2"
   kind: rule
   metadata:
     name: handle-cnn-access
     namespace: istio-system
   spec:
     match: request.host.endsWith(".cnn.com") && context.reporter.uid.startsWith("kubernetes://istio-egressgateway")
     actions:
     - handler: egress-access-logger.stdio
       instances:
         - egress-access.logentry
   EOF
   

2. 向 cnn.com 发送三个 HTTP 请求，分别发送到 edition.cnn.com/politics、edition.cnn.com/sport 和 edition.cnn.com/health。所有三个请求都应返回200 OK。

   $ kubectl exec -it $SOURCE_POD -c sleep -- sh -c 'curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/politics; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/sport; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/health'
   200
   200
   200
   

3. 查询 Mixer 日志，并查看请求信息是否出现在日志中

   $ kubectl -n istio-system logs -l istio-mixer-type=telemetry -c mixer | grep egress-access | grep cnn | tail -4
   {"level":"info","time":"2019-01-29T07:43:24.611462Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/politics","reporterUID":"kubernetes://istio-egressgateway-747b6764b8-44rrh.istio-system","responseCode":200,"responseSize":1883355,"sourcePrincipal":"cluster.local/ns/default/sa/sleep"}
   {"level":"info","time":"2019-01-29T07:43:24.886316Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/sport","reporterUID":"kubernetes://istio-egressgateway-747b6764b8-44rrh.istio-system","responseCode":200,"responseSize":2094561,"sourcePrincipal":"cluster.local/ns/default/sa/sleep"}
   {"level":"info","time":"2019-01-29T07:43:25.369663Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/health","reporterUID":"kubernetes://istio-egressgateway-747b6764b8-44rrh.istio-system","responseCode":200,"responseSize":2157009,"sourcePrincipal":"cluster.local/ns/default/sa/sleep"}
   {"level":"error","time":"2019-01-29T07:43:24.611462Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/politics","reporterUID":"kubernetes://istio-egressgateway-747b6764b8-44rrh.istio-system","responseCode":200,"responseSize":1883355,"sourcePrincipal":"cluster.local/ns/default/sa/sleep"}
   

   您会看到与您的三个请求相关的四个日志条目。三个关于对 edition.cnn.com 的访问的信息条目和一个关于对 edition.cnn.com/politics 的访问的错误条目。服务网格运营商可以查看所有访问实例，还可以搜索代表被禁止访问的错误日志条目。这是组织在自动阻止被禁止访问之前可以应用的第一项安全措施，即以错误的形式记录所有被禁止的访问实例。在某些设置中，这可能是一项足够的安全措施。

   注意属性

   • destination、path、responseCode、responseSize 与请求的 HTTP 参数相关
   • sourcePrincipal:cluster.local/ns/default/sa/sleep - 表示 default 命名空间中 sleep 服务帐户的字符串
   • reporterUID: kubernetes://istio-egressgateway-747b6764b8-44rrh.istio-system - 报告 Pod 的 UID，在本例中，istio-system 命名空间中的 istio-egressgateway-747b6764b8-44rrh

通过路由进行访问控制

启用对 edition.cnn.com 的访问日志记录后，自动执行访问策略，即仅允许访问 /health 和 /sport URL 路径。可以使用 Istio 路由实现此类简单的策略控制。

1. 重新定义 edition.cnn.com 的 VirtualService

   $ cat <<EOF | kubectl apply -f -
   apiVersion: networking.istio.io/v1alpha3
   kind: VirtualService
   metadata:
     name: direct-cnn-through-egress-gateway
   spec:
     hosts:
     - edition.cnn.com
     gateways:
     - istio-egressgateway
     - mesh
     http:
     - match:
       - gateways:
         - mesh
         port: 80
       route:
       - destination:
           host: istio-egressgateway.istio-system.svc.cluster.local
           subset: cnn
           port:
             number: 443
         weight: 100
     - match:
       - gateways:
         - istio-egressgateway
         port: 443
         uri:
           regex: "/health|/sport"
       route:
       - destination:
           host: edition.cnn.com
           port:
             number: 443
         weight: 100
   EOF
   

   请注意，您通过 uri 条件添加了一个 match，该条件检查 URL 路径是否为 /health 或 /sport。另请注意，此条件已添加到 VirtualService 的 istio-egressgateway 部分，因为出站网关是安全方面的一个强化组件（请参阅 [出站网关安全注意事项] (/docs/tasks/traffic-management/egress/egress-gateway/#additional-security-considerations)）。您不希望对策略进行任何篡改。

2. 发送先前的三个 HTTP 请求到 cnn.com

   $ kubectl exec -it $SOURCE_POD -c sleep -- sh -c 'curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/politics; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/sport; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/health'
   404
   200
   200
   

   对 edition.cnn.com/politics 的请求返回404 未找到，而对 edition.cnn.com/sport 和 edition.cnn.com/health 的请求返回200 OK，符合预期。

3. 查询 Mixer 日志，并查看请求信息是否再次出现在日志中

   $ kubectl -n istio-system logs -l istio-mixer-type=telemetry -c mixer | grep egress-access | grep cnn | tail -4
   {"level":"info","time":"2019-01-29T07:55:59.686082Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/politics","reporterUID":"kubernetes://istio-egressgateway-747b6764b8-44rrh.istio-system","responseCode":404,"responseSize":0,"sourcePrincipal":"cluster.local/ns/default/sa/sleep"}
   {"level":"info","time":"2019-01-29T07:55:59.697565Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/sport","reporterUID":"kubernetes://istio-egressgateway-747b6764b8-44rrh.istio-system","responseCode":200,"responseSize":2094561,"sourcePrincipal":"cluster.local/ns/default/sa/sleep"}
   {"level":"info","time":"2019-01-29T07:56:00.264498Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/health","reporterUID":"kubernetes://istio-egressgateway-747b6764b8-44rrh.istio-system","responseCode":200,"responseSize":2157009,"sourcePrincipal":"cluster.local/ns/default/sa/sleep"}
   {"level":"error","time":"2019-01-29T07:55:59.686082Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/politics","reporterUID":"kubernetes://istio-egressgateway-747b6764b8-44rrh.istio-system","responseCode":404,"responseSize":0,"sourcePrincipal":"cluster.local/ns/default/sa/sleep"}
   

   您仍然会收到有关对 edition.cnn.com/politics 的访问的信息和错误消息，但是这次 responseCode 为 404，符合预期。

虽然在本简单案例中使用 Istio 路由实现访问控制对我们有效，但它不适用于更复杂的案例。例如，该组织可能希望在某些条件下允许访问 edition.cnn.com/politics，因此需要比仅按 URL 路径过滤更复杂的策略逻辑。您可能希望应用Istio Mixer 适配器，例如允许/禁止 URL 路径的白名单或黑名单。 策略规则允许指定复杂条件，这些条件在丰富的表达式语言中指定，其中包括 AND 和 OR 逻辑运算符。这些规则可以重复用于日志记录和策略检查。更高级的用户可能希望应用Istio 基于角色的访问控制。

另一个方面是与远程访问策略系统的集成。如果我们用例中的组织运行一些身份和访问管理系统，您可能希望配置 Istio 以使用来自此类系统的访问策略信息。您可以通过应用Istio Mixer 适配器来实现此集成。

取消本节中使用的通过路由进行的访问控制，并在下一节中通过 Mixer 策略检查实现访问控制。

1. 将 edition.cnn.com 的 VirtualService 替换为来自配置出站网关示例的先前版本

   $ cat <<EOF | kubectl apply -f -
   apiVersion: networking.istio.io/v1alpha3
   kind: VirtualService
   metadata:
     name: direct-cnn-through-egress-gateway
   spec:
     hosts:
     - edition.cnn.com
     gateways:
     - istio-egressgateway
     - mesh
     http:
     - match:
       - gateways:
         - mesh
         port: 80
       route:
       - destination:
           host: istio-egressgateway.istio-system.svc.cluster.local
           subset: cnn
           port:
             number: 443
         weight: 100
     - match:
       - gateways:
         - istio-egressgateway
         port: 443
       route:
       - destination:
           host: edition.cnn.com
           port:
             number: 443
         weight: 100
   EOF
   

2. 发送先前的三个 HTTP 请求到 cnn.com，这次您应该像以前一样获得三个200 OK响应

   $ kubectl exec -it $SOURCE_POD -c sleep -- sh -c 'curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/politics; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/sport; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/health'
   200
   200
   200
   

通过 Mixer 策略检查进行访问控制

在此步骤中，您使用 Mixer Listchecker 适配器及其白名单变体。您使用请求的 URL 路径定义一个 listentry，并使用一个 listchecker 来使用 overrides 字段中指定的允许 URL 路径的静态列表检查 listentry。对于外部身份和访问管理系统，请改用 providerurl 字段。下面显示了实例、规则和处理程序的更新图表。请注意，您将相同的策略规则 handle-cnn-access 重复用于日志记录和访问策略检查。

1. 定义 path-checker 和 request-path

   $ cat <<EOF | kubectl create -f -
   apiVersion: "config.istio.io/v1alpha2"
   kind: listchecker
   metadata:
     name: path-checker
     namespace: istio-system
   spec:
     overrides: ["/health", "/sport"]  # overrides provide a static list
     blacklist: false
   ---
   apiVersion: "config.istio.io/v1alpha2"
   kind: listentry
   metadata:
     name: request-path
     namespace: istio-system
   spec:
     value: request.path
   EOF
   

2. 修改 handle-cnn-access 策略规则，以将 request-path 实例发送到 path-checker

   $ cat <<EOF | kubectl apply -f -
   # Rule handle egress access to cnn.com
   apiVersion: "config.istio.io/v1alpha2"
   kind: rule
   metadata:
     name: handle-cnn-access
     namespace: istio-system
   spec:
     match: request.host.endsWith(".cnn.com") && context.reporter.uid.startsWith("kubernetes://istio-egressgateway")
     actions:
     - handler: egress-access-logger.stdio
       instances:
         - egress-access.logentry
     - handler: path-checker.listchecker
       instances:
         - request-path.listentry
   EOF
   

3. 通过向 edition.cnn.com/politics、edition.cnn.com/sport 和 edition.cnn.com/health 发送 HTTP 请求来执行您通常的测试。如预期的那样，对 edition.cnn.com/politics 的请求返回 403（禁止访问）。

   $ kubectl exec -it $SOURCE_POD -c sleep -- sh -c 'curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/politics; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/sport; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/health'
   403
   200
   200
   

Mixer 策略检查的访问控制，第 2 部分

在我们用例中，组织在成功配置日志记录和访问控制后，决定扩展其访问策略，允许具有特殊 服务账户 的应用程序访问 cnn.com 的任何主题，而无需进行监控。您将看到如何在 Istio 中配置此需求。

1. 使用 politics 服务账户启动 sleep 示例。

   压缩

   $  sed 's/: sleep/: politics/g' @samples/sleep/sleep.yaml@ | kubectl create -f -
   serviceaccount "politics" created
   service "politics" created
   deployment "politics" created
   

2. 定义 SOURCE_POD_POLITICS shell 变量以保存具有 politics 服务账户的源 Pod 的名称，用于向外部服务发送请求。

   $ export SOURCE_POD_POLITICS=$(kubectl get pod -l app=politics -o jsonpath={.items..metadata.name})
   

3. 执行您通常的测试，这次从 SOURCE_POD_POLITICS 发送三个 HTTP 请求。对 edition.cnn.com/politics 的请求返回 403，因为您没有为 politics 命名空间配置异常。

   $ kubectl exec -it $SOURCE_POD_POLITICS -c politics -- sh -c 'curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/politics; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/sport; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/health'
   403
   200
   200
   

4. 查询 Mixer 日志，并查看来自 politics 命名空间的请求信息是否出现在日志中。

   $ kubectl -n istio-system logs -l istio-mixer-type=telemetry -c mixer | grep egress-access | grep cnn | tail -4
   {"level":"info","time":"2019-01-29T08:04:42.559812Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/politics","reporterUID":"kubernetes://istio-egressgateway-747b6764b8-44rrh.istio-system","responseCode":403,"responseSize":84,"sourcePrincipal":"cluster.local/ns/default/sa/politics"}
   {"level":"info","time":"2019-01-29T08:04:42.568424Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/sport","reporterUID":"kubernetes://istio-egressgateway-747b6764b8-44rrh.istio-system","responseCode":200,"responseSize":2094561,"sourcePrincipal":"cluster.local/ns/default/sa/politics"}
   {"level":"error","time":"2019-01-29T08:04:42.559812Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/politics","reporterUID":"kubernetes://istio-egressgateway-747b6764b8-44rrh.istio-system","responseCode":403,"responseSize":84,"sourcePrincipal":"cluster.local/ns/default/sa/politics"}
   {"level":"info","time":"2019-01-29T08:04:42.615641Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/health","reporterUID":"kubernetes://istio-egressgateway-747b6764b8-44rrh.istio-system","responseCode":200,"responseSize":2157009,"sourcePrincipal":"cluster.local/ns/default/sa/politics"}
   

   请注意，sourcePrincipal 为 cluster.local/ns/default/sa/politics，它表示 default 命名空间中的 politics 服务账户。

5. 重新定义 handle-cnn-access 和 handle-politics 策略规则，使 politics 命名空间中的应用程序免于监控和策略执行。

   $ cat <<EOF | kubectl apply -f -
   # Rule to handle access to *.cnn.com/politics
   apiVersion: "config.istio.io/v1alpha2"
   kind: rule
   metadata:
     name: handle-politics
     namespace: istio-system
   spec:
     match: request.host.endsWith("cnn.com") && context.reporter.uid.startsWith("kubernetes://istio-egressgateway") && request.path.startsWith("/politics") && source.principal != "cluster.local/ns/default/sa/politics"
     actions:
     - handler: egress-error-logger.stdio
       instances:
       - egress-access.logentry
   ---
   # Rule handle egress access to cnn.com
   apiVersion: "config.istio.io/v1alpha2"
   kind: rule
   metadata:
     name: handle-cnn-access
     namespace: istio-system
   spec:
     match: request.host.endsWith(".cnn.com") && context.reporter.uid.startsWith("kubernetes://istio-egressgateway") && source.principal != "cluster.local/ns/default/sa/politics"
     actions:
     - handler: egress-access-logger.stdio
       instances:
         - egress-access.logentry
     - handler: path-checker.listchecker
       instances:
         - request-path.listentry
   EOF
   

6. 从 SOURCE_POD 执行您通常的测试。

   $ kubectl exec -it $SOURCE_POD -c sleep -- sh -c 'curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/politics; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/sport; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/health'
   403
   200
   200
   

   由于 SOURCE_POD 没有 politics 服务账户，因此与之前一样，对 edition.cnn.com/politics 的访问被禁止。

7. 从 SOURCE_POD_POLITICS 执行之前的测试。

   $ kubectl exec -it $SOURCE_POD_POLITICS -c politics -- sh -c 'curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/politics; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/sport; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/health'
   200
   200
   200
   

   允许访问 edition.cnn.com 的所有主题。

8. 检查 Mixer 日志，并查看日志中是否不再出现 sourcePrincipal 等于 cluster.local/ns/default/sa/politics 的请求。

   $  kubectl -n istio-system logs -l istio-mixer-type=telemetry -c mixer | grep egress-access | grep cnn | tail -4
   

与 HTTPS 出站流量控制的比较

在此用例中，应用程序使用 HTTP，Istio 出站网关为其执行 TLS 发起。或者，应用程序可以通过向 edition.cnn.com 发出 HTTPS 请求来自己发起 TLS。在本节中，我们将描述这两种方法及其优缺点。

在 HTTP 方法中，请求在本地主机上未加密发送，被 Istio sidecar 代理拦截并转发到出站网关。由于您配置 Istio 在 sidecar 代理和出站网关之间使用双向 TLS，因此流量以加密方式离开 Pod。出站网关解密流量，检查 URL 路径、HTTP 方法和标头，报告遥测数据并执行策略检查。如果请求未被某些策略检查阻止，则出站网关会对外部目标（在本例中为 cnn.com）执行 TLS 发起，因此请求再次加密并以加密方式发送到外部目标。下图演示了此方法的网络流量。网关内部的 HTTP 协议表示解密后网关看到的协议。

此方法的缺点是请求在 Pod 内未加密发送，这可能违反某些组织的安全策略。此外，一些 SDK 具有硬编码的外部服务 URL，包括协议，因此发送 HTTP 请求可能是不可能的。此方法的优点是可以检查 HTTP 方法、标头和 URL 路径，并根据它们应用策略。

在 HTTPS 方法中，请求从应用程序到外部目标端到端加密。下图演示了此方法的网络流量。网关内部的 HTTPS 协议表示网关看到的协议。

从安全角度来看，端到端 HTTPS 被认为是一种更好的方法。但是，由于流量已加密，因此 Istio 代理和出站网关只能看到源和目标 IP 以及目标的 SNI。由于您配置 Istio 在 sidecar 代理和出站网关之间使用双向 TLS，因此也已知 源的身份。网关无法检查请求的 URL 路径、HTTP 方法和标头，因此无法基于 HTTP 信息进行监控和策略。在我们的用例中，组织将能够允许访问 edition.cnn.com 并指定哪些应用程序可以访问 edition.cnn.com。但是，将无法允许或阻止对 edition.cnn.com 的特定 URL 路径的访问。使用 HTTPS 方法也无法阻止对 edition.cnn.com/politics 的访问或监控此类访问。

我们认为每个组织都会权衡这两种方法的优缺点，并选择最适合其需求的方法。

总结

在这篇博文中，我们展示了如何将 Istio 的不同监控和策略机制应用于 HTTP 出站流量。可以通过配置日志记录适配器来实现监控。可以通过配置 VirtualServices 或配置各种策略检查适配器来实现访问策略。我们演示了一个简单的策略，该策略仅允许某些 URL 路径。我们还展示了一个更复杂的策略，该策略通过对具有特定服务账户的应用程序进行豁免来扩展简单策略。最后，我们从 Istio 的控制可能性方面比较了带有 TLS 发起的 HTTP 出站流量和 HTTPS 出站流量。

清理

1. 执行 配置出站网关 示例的 清理 部分中的说明。

2. 删除日志记录和策略检查配置。

   $ kubectl delete logentry egress-access -n istio-system
   $ kubectl delete stdio egress-error-logger -n istio-system
   $ kubectl delete stdio egress-access-logger -n istio-system
   $ kubectl delete rule handle-politics -n istio-system
   $ kubectl delete rule handle-cnn-access -n istio-system
   $ kubectl delete -n istio-system listchecker path-checker
   $ kubectl delete -n istio-system listentry request-path
   

3. 删除 politics 源 Pod。

   压缩

   $ sed 's/: sleep/: politics/g' @samples/sleep/sleep.yaml@ | kubectl delete -f -
   serviceaccount "politics" deleted
   service "politics" deleted
   deployment "politics" deleted