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 原始化的出口閘道 範例示範了如何允許應用程式將 HTTP 請求傳送至需要 HTTPS 的外部伺服器，同時將流量導向出口閘道。
• 使用 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，一個用於記錄被禁止的存取（error 日誌層級），另一個用於記錄對 *.cnn.com 的所有存取（info 日誌層級）。然後，您建立 rules，將您的 logentry 執行個體導向您的 handlers。一條規則將對 *.cnn.com/politics 的存取導向用於記錄被禁止存取的處理程式，另一條規則將日誌條目導向輸出對 *.cnn.com 的每次存取的處理程式，作為 info 日誌條目。若要了解 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. 將三個 HTTP 請求傳送至 cnn.com、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 的 info 條目和一個關於存取 edition.cnn.com/politics 的 error 條目。服務網格運營商可以看到所有存取執行個體，還可以搜尋日誌中代表被禁止存取的 error 日誌條目。這是該組織可以在自動阻止被禁止存取之前應用的第一種安全措施，也就是將所有被禁止的存取執行個體記錄為錯誤。在某些情況下，這可能是一種足夠的安全措施。

   請注意以下屬性

   • 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-egressgateway-747b6764b8-44rrh，位於 istio-system 命名空間中

透過路由進行存取控制

在啟用對 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 Not Found*，而對 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 的 info 和 error 訊息，但這次 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 适配器，這是其白名單變體。您會定義一個 listentry，其中包含請求的 URL 路徑，以及一個 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. 通過將 HTTP 請求發送到 edition.cnn.com/politics、edition.cnn.com/sport 和 edition.cnn.com/health 來執行您常用的測試。如預期，對 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 Proxy 攔截並轉發到輸出閘道。由於您配置 Istio 在 Sidecar Proxy 和輸出閘道之間使用相互 TLS，因此流量離開 Pod 時會加密。輸出閘道會解密流量，檢查 URL 路徑、HTTP 方法和標頭，報告遙測資料並執行策略檢查。如果請求未被某些策略檢查阻止，輸出閘道會對外部目標（在本例中為 cnn.com）執行 TLS 起源，因此請求會再次加密並以加密方式傳送到外部目標。下圖展示了此方法的網路流程。閘道內部的 HTTP 協定指定為閘道解密後看到的協定。

此方法的缺點是請求在 Pod 內以未加密的方式傳送，這可能違反某些組織的安全策略。此外，某些 SDK 具有硬式編碼的外部服務 URL，包括協定，因此可能無法發送 HTTP 請求。此方法的優點是能夠檢查 HTTP 方法、標頭和 URL 路徑，並根據它們應用策略。

在 HTTPS 方法中，請求從應用程式到外部目標進行端對端加密。下圖展示了此方法的網路流程。閘道內部的 HTTPS 協定指定為閘道看到的協定。

從安全的角度來看，端對端 HTTPS 被認為是更好的方法。但是，由於流量已加密，Istio Proxy 和輸出閘道只能看到來源和目標 IP 以及目標的 SNI。由於您配置 Istio 在 Sidecar Proxy 和輸出閘道之間使用相互 TLS，因此也知道來源的身分。閘道無法檢查請求的 URL 路徑、HTTP 方法和標頭，因此無法根據 HTTP 資訊進行任何監控和策略。在我們的使用案例中，組織將能夠允許存取 edition.cnn.com 並指定允許哪些應用程式存取 edition.cnn.com。但是，無法允許或阻止存取 edition.cnn.com 的特定 URL 路徑。使用 HTTPS 方法無法阻止存取 edition.cnn.com/politics，也無法監控此類存取。

我們猜想每個組織都會考慮這兩種方法的優缺點，並選擇最適合其需求的方法。

總結

在這篇部落格文章中，我們展示了如何將 Istio 的不同監控和策略機制應用於 HTTP 輸出流量。監控可以通過配置記錄适配器來實現。存取策略可以通過配置 VirtualServices 或配置各種策略檢查适配器來實現。我們展示了一個簡單的策略，僅允許某些 URL 路徑。我們還展示了一個更複雜的策略，該策略通過對具有特定服務帳戶的應用程式進行豁免來擴展簡單策略。最後，我們比較了具有 TLS 起源的 HTTP 輸出流量與 HTTPS 輸出流量在 Istio 的控制可能性方面的差異。

清理

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