安全最佳實務

閱讀時間 22 分鐘

Istio 安全功能提供強大的身分驗證、強大的政策、透明的 TLS 加密，以及身分驗證、授權和稽核 (AAA) 工具，以保護您的服務和資料。然而，為了完全安全地利用這些功能，必須謹慎遵循最佳實務。建議您在繼續之前先查看安全概觀。

相互 TLS

Istio 將在可行的情況下，自動使用相互 TLS 加密流量。然而，預設情況下，Proxy 會以寬鬆模式設定，這表示它們將接受相互 TLS 和純文字流量。

雖然這是增量採用或允許來自沒有 Istio Sidecar 的用戶端流量所必需的，但它也會削弱安全立場。建議在可能的情況下移轉到嚴格模式，以強制使用相互 TLS。

然而，僅靠相互 TLS 並不足以完全保護流量安全，因為它僅提供身分驗證，而不提供授權。這表示任何擁有有效憑證的人仍然可以存取服務。

為了完全鎖定流量，建議設定授權政策。這些政策允許建立精細的政策來允許或拒絕流量。例如，您可以只允許來自 app 命名空間的請求存取 hello-world 服務。

授權原則

Istio 的授權在 Istio 安全性中扮演著至關重要的角色。需要努力設定正確的授權政策，以最好地保護您的叢集。重要的是要了解這些設定的影響，因為 Istio 無法為所有使用者決定適當的授權。請完整遵循本節。

更安全的授權原則模式

使用預設拒絕模式

我們建議您遵循預設拒絕模式定義 Istio 授權政策，以增強叢集的安全性。預設拒絕授權模式表示您的系統預設拒絕所有請求，而您定義允許請求的條件。如果您遺漏了一些條件，則會意外拒絕流量，而不是意外允許流量。後者通常是安全事件，而前者可能會導致使用者體驗不佳、服務中斷或與您的 SLO/SLA 不符。

例如，在HTTP 流量授權工作中，名為 allow-nothing 的授權政策確保預設情況下拒絕所有流量。從那裡開始，其他授權政策會根據特定條件允許流量。

使用 `ALLOW-with-positive-matching` 和 `DENY-with-negative-match` 模式

盡可能使用 ALLOW-with-positive-matching 或 DENY-with-negative-matching 模式。這些授權政策模式更安全，因為在政策不符的情況下，最壞的結果是意外的 403 拒絕，而不是繞過授權政策。

ALLOW-with-positive-matching 模式是僅將 ALLOW 動作與正向比對欄位（例如 paths、values）一起使用，而不使用任何負向比對欄位（例如 notPaths、notValues）。

DENY-with-negative-matching 模式是僅將 DENY 動作與負向比對欄位（例如 notPaths、notValues）一起使用，而不使用任何正向比對欄位（例如 paths、values）。

例如，下面的授權政策使用 ALLOW-with-positive-matching 模式來允許對路徑 /public 的請求

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: foo
spec:
  action: ALLOW
  rules:
  - to:
    - operation:
        paths: ["/public"]

上面的政策明確列出了允許的路徑 (/public)。這表示請求路徑必須與 /public 完全相同才能允許請求。任何其他請求都將預設被拒絕，從而消除了由於未知的正規化行為導致策略繞過的風險。

以下是使用 DENY-with-negative-matching 模式達成相同結果的範例

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: foo
spec:
  action: DENY
  rules:
  - to:
    - operation:
        notPaths: ["/public"]

了解授權原則中的路徑正規化

授權政策的強制執行點是 Envoy Proxy，而不是後端應用程式中常用的資源存取點。當 Envoy Proxy 和後端應用程式以不同方式解讀請求時，會發生政策不符的情況。

不符的情況可能會導致意外的拒絕或繞過政策。後者通常是需要立即修復的安全事件，這也是為什麼我們需要在授權政策中進行路徑正規化的原因。

例如，考慮一個授權政策，拒絕路徑為 /data/secret 的請求。路徑為 /data//secret 的請求將不會被拒絕，因為它與授權政策中定義的路徑不符，因為路徑中有多餘的斜線 /。

請求會通過，稍後後端應用程式會傳回與路徑 /data/secret 相同的回應，因為後端應用程式會將路徑 /data//secret 正規化為 /data/secret，因為它會將雙斜線 // 視為等同於單斜線 /。

在此範例中，政策強制執行點 (Envoy Proxy) 對路徑的理解與資源存取點 (後端應用程式) 不同。不同的理解導致了不符，並隨後繞過了授權政策。

由於以下因素，這變成一個複雜的問題

缺乏明確的正規化標準。
不同層的後端和框架都有自己的特殊正規化。
應用程式甚至可以針對自己的使用案例進行任意正規化。

Istio 授權政策實作了各種基本正規化選項的內建支援，以幫助您更好地解決問題

請參閱關於設定路徑正規化選項的指南，以了解您可能想要使用的正規化選項。
請參閱在路徑正規化上自訂系統，以了解每個正規化選項的詳細資訊。
如果需要任何不支援的正規化選項，請參閱不支援的正規化之緩解，以取得替代方案。

關於設定路徑正規化選項的指南

案例 1：您完全不需要正規化

在深入了解設定正規化的詳細資訊之前，您應先確定是否需要正規化。

如果您不使用授權政策，或授權政策不使用任何 path 欄位，則不需要正規化。

如果您的所有授權政策都遵循更安全的授權模式，則您可能不需要正規化，在最壞的情況下，該模式會導致意外的拒絕而不是繞過政策。

案例 2：您需要正規化，但不確定要使用哪個正規化選項

您需要正規化，但不知道要使用哪個選項。最安全的選擇是提供授權政策中最大程度正規化的最嚴格正規化選項。

通常情況下，由於複雜的多層系統使得幾乎不可能找出正規化實際上在強制執行點之外對請求發生了什麼。

如果它已滿足您的需求，並且您確定其影響，則可以使用較不嚴格的正規化選項。

對於這兩種選項，請確保您為需求特別編寫正面和負面測試，以驗證正規化是否按預期工作。這些測試有助於捕獲由於對請求發生的正規化理解錯誤或不完全了解而造成的潛在繞過問題。

請參閱在路徑正規化上自訂系統，以了解有關設定正規化選項的更多詳細資訊。

案例 3：您需要不受支援的正規化選項

如果您需要 Istio 尚不支援的特定正規化選項，請遵循不支援的正規化之緩解，以取得自訂正規化支援，或為 Istio 社群建立功能請求。

客製化您系統上的路徑正規化

Istio 授權政策可以基於 HTTP 請求中的 URL 路徑。路徑正規化 (又稱 URI 正規化) 會修改和標準化傳入請求的路徑，以便可以以標準方式處理正規化的路徑。語法上不同的路徑在路徑正規化後可能等效。

Istio 在評估授權政策和路由請求之前，支援請求路徑上的以下正規化方案

選項	描述	範例
`NONE`	不進行正規化。Envoy 收到的任何內容都將完全按照原樣轉發到任何後端服務。	授權政策將評估 `../%2Fa../b` 並將其傳送到您的服務。
`BASE`	這是目前 Istio 預設安裝中使用的選項。這會將 `normalize_path` 選項套用至 Envoy Proxy，該選項遵循 RFC 3986，並額外進行正規化，將反斜線轉換為斜線。	`/a/../b` 正規化為 `/b`。`\da` 正規化為 `/da`。
`MERGE_SLASHES`	在 BASE 正規化之後，會合併斜線。	`/a//b` 正規化為 `/a/b`。
`DECODE_AND_MERGE_SLASHES`	當您預設允許所有流量時，這是最嚴格的設定。建議使用此設定，但請注意，您需要徹底測試您的授權政策路由。百分比編碼的斜線和反斜線字元 (`%2F`、`%2f`、`%5C` 和 `%5c`) 在 `MERGE_SLASHES` 正規化之前會解碼為 `/` 或 `\`。	`/a%2fb` 正規化為 `/a/b`。

強調一下，正規化演算法會按照以下順序執行

百分比解碼 %2F、%2f、%5C 和 %5c。
RFC 3986 和由 Envoy 中的 normalize_path 選項實作的其他正規化。
合併斜線

如需完整的支援正規化列表，請參閱授權政策正規化。

設定範例

確保 Envoy 將請求路徑正規化以符合後端服務的期望，對於系統的安全性至關重要。您可以使用以下範例作為配置系統的參考。正規化後的 URL 路徑，或如果選擇 NONE 則使用原始 URL 路徑，將會被

用來檢查授權政策
轉發至後端應用程式

您的應用程式…	選擇…
依賴代理伺服器進行正規化	`BASE`、`MERGE_SLASHES` 或 `DECODE_AND_MERGE_SLASHES`
根據 RFC 3986 正規化請求路徑，但不合併斜線	`BASE`
根據 RFC 3986 正規化請求路徑，合併斜線但不解碼百分比編碼的斜線	`MERGE_SLASHES`
根據 RFC 3986 正規化請求路徑，解碼百分比編碼的斜線並合併斜線	`DECODE_AND_MERGE_SLASHES`
以與 RFC 3986 不相容的方式處理請求路徑	`NONE`

如何設定

您可以使用 istioctl 來更新網格配置

$ istioctl upgrade --set meshConfig.pathNormalization.normalization=DECODE_AND_MERGE_SLASHES

或修改您的運算子覆寫檔案

$ cat <<EOF > iop.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    pathNormalization:
      normalization: DECODE_AND_MERGE_SLASHES
EOF
$ istioctl install -f iop.yaml

或者，如果您想直接編輯網格配置，您可以將 pathNormalization 新增到網格配置，這是 istio-<REVISION_ID> ConfigMap 在 istio-system 命名空間中。例如，如果您選擇 DECODE_AND_MERGE_SLASHES 選項，您應按如下方式修改網格配置

apiVersion: v1
  data:
    mesh: |-
      ...
      pathNormalization:
        normalization: DECODE_AND_MERGE_SLASHES
      ...

不受支援的正規化的緩解措施

本節描述各種針對不支援正規化的緩解措施。當您需要 Istio 不支援的特定正規化時，這些措施可能會很有用。

請確保您徹底理解緩解措施並謹慎使用，因為有些緩解措施依賴於 Istio 範圍之外的事物，並且 Istio 不支援這些事物。

自訂正規化邏輯

您可以使用 WASM 或 Lua 過濾器應用自訂正規化邏輯。建議使用 WASM 過濾器，因為它是官方支援且 Istio 也使用的過濾器。您可以使用 Lua 過濾器進行快速概念驗證 DEMO，但不建議在生產環境中使用 Lua 過濾器，因為 Istio 不支援它。

範例自訂正規化 (案例正規化)

在某些環境中，可能需要以不區分大小寫的方式比較授權政策中的路徑。例如，將 https://myurl/get 和 https://myurl/GeT 視為等效。

在這些情況下，可以使用下面顯示的 EnvoyFilter 插入 Lua 過濾器，將路徑正規化為小寫。此過濾器將變更用於比較的路徑和呈現給應用程式的路徑。

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: ingress-case-insensitive
  namespace: istio-system
spec:
  configPatches:
  - applyTo: HTTP_FILTER
    match:
      context: GATEWAY
      listener:
        filterChain:
          filter:
            name: "envoy.filters.network.http_connection_manager"
    patch:
      operation: INSERT_FIRST
      value:
        name: envoy.lua
        typed_config:
            "@type": "type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua"
            inlineCode: |
              function envoy_on_request(request_handle)
                local path = request_handle:headers():get(":path")
                request_handle:headers():replace(":path", string.lower(path))
              end

撰寫主機比對原則

Istio 會為主機名稱本身和所有相符的連接埠產生主機名稱。例如，example.com 主機的虛擬服務或閘道會產生與 example.com 和 example.com:* 相符的設定。但是，完全相符的授權政策只會比對 hosts 或 notHosts 欄位中給定的確切字串。

比對主機的授權政策規則應使用前綴比對，而不是完全比對。例如，對於符合為 example.com 主機名稱產生的 Envoy 設定的 AuthorizationPolicy，您應使用 hosts: ["example.com", "example.com:*"]，如下面的 AuthorizationPolicy 所示。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: ingress-host
  namespace: istio-system
spec:
  selector:
    matchLabels:
      app: istio-ingressgateway
  action: DENY
  rules:
  - to:
    - operation:
        hosts: ["example.com", "example.com:*"]

此外，host 和 notHosts 欄位通常只應在閘道上用於進入網格的外部流量，而不應在邊車上用於網格內的流量。這是因為伺服器端的邊車（強制執行授權政策的地方）在將請求重新導向到應用程式時不會使用 Host 標頭。這使得 host 和 notHost 在邊車上毫無意義，因為用戶端可以使用明確的 IP 位址和任意 Host 標頭來連線到應用程式，而不是使用服務名稱。

如果您真的需要在邊車上根據 Host 標頭強制執行存取控制，請遵循預設拒絕模式，如果用戶端使用任意 Host 標頭，則會拒絕請求。

專業的 Web 應用程式防火牆 (WAF)

許多專業的 Web 應用程式防火牆 (WAF) 產品提供額外的正規化選項。它們可以部署在 Istio 入口閘道的前面，以正規化進入網格的請求。然後，將在正規化後的請求上強制執行授權政策。請參閱您的特定 WAF 產品以設定正規化選項。

Istio 的功能要求

如果您認為 Istio 應正式支援特定正規化，您可以按照回報漏洞頁面，將有關特定正規化的功能要求發送給 Istio 產品安全工作小組進行初步評估。

請勿在未先聯繫 Istio 產品安全工作小組的情況下公開提出任何問題，因為該問題可能被視為需要在私人解決的安全性漏洞。

如果 Istio 產品安全工作小組將功能要求評估為非安全性漏洞，將會公開提出問題，以便進一步討論該功能要求。

已知限制

本節列出授權政策的已知限制。

不支援伺服器優先 TCP 通訊協定

伺服器優先 TCP 協定表示伺服器應用程式會在接受 TCP 連線後立即傳送第一個位元組，然後才會收到來自用戶端的任何資料。

目前，授權政策僅支援對輸入流量強制執行存取控制，而不支援輸出流量。

它也不支援伺服器優先 TCP 協定，因為第一個位元組是由伺服器應用程式傳送的，甚至在收到來自用戶端的任何資料之前就已傳送。在這種情況下，伺服器傳送的初始第一個位元組會直接返回給用戶端，而無需通過授權政策的存取控制檢查。

如果伺服器優先 TCP 協定傳送的第一個位元組包含任何需要透過適當授權來保護的敏感資料，則不應使用授權政策。

如果第一個位元組不包含任何敏感資料，您仍然可以在這種情況下使用授權政策，例如，第一個位元組用於與任何用戶端都可以公開存取的資料協商連線。對於第一個位元組之後用戶端傳送的後續請求，授權政策將會正常運作。

了解流量擷取限制

Istio 邊車的工作原理是捕獲輸入流量和輸出流量，並將它們導向通過邊車代理伺服器。

但是，並非所有流量都會被捕獲

重新導向僅處理基於 TCP 的流量。任何 UDP 或 ICMP 封包都不會被捕獲或修改。
在許多邊車使用的連接埠以及連接埠 22 上，輸入捕獲已停用。此清單可以透過 traffic.sidecar.istio.io/excludeInboundPorts 等選項擴充。
輸出捕獲類似地可以透過 traffic.sidecar.istio.io/excludeOutboundPorts 或其他方式來減少。

一般而言，應用程式及其邊車代理伺服器之間的安全邊界非常小。允許在每個 Pod 的基礎上設定邊車，並且兩者在相同的網路/處理程序命名空間中執行。因此，應用程式可能具有移除重新導向規則、移除、變更、終止或取代邊車代理伺服器的能力。這允許 Pod 有意繞過其邊車以進行輸出流量，或有意允許輸入流量繞過其邊車。

因此，依賴 Istio 無條件捕獲所有流量是不安全的。相反地，安全邊界是用戶端不得繞過另一個 Pod 的邊車。

例如，如果我在連接埠 9080 上執行 reviews 應用程式，我可以假設來自 productpage 應用程式的所有流量都將被邊車代理伺服器捕獲，Istio 驗證和授權政策可以在其中應用。

使用 `NetworkPolicy` 的深度防禦

為了進一步保護流量，Istio 政策可以與 Kubernetes 網路政策分層。這使得強大的縱深防禦策略可用於進一步加強網格的安全性。

例如，您可以選擇僅允許流量流向我們的 reviews 應用程式的連接埠 9080。如果叢集中存在受損的 Pod 或安全性漏洞，這可能會限制或阻止攻擊者的進展。

根據實際實作方式，對網路政策的變更可能不會影響 Istio 代理伺服器中的現有連線。您可能需要在套用政策後重新啟動 Istio 代理伺服器，以便關閉現有連線，並且新的連線將會受到新政策的約束。

保護出口流量

一個常見的誤解是，像 outboundTrafficPolicy: REGISTRY_ONLY 這樣的選項充當安全政策，防止存取未宣告的服務。但是，這不是一個強大的安全邊界，如上所述，應被視為盡力而為。

雖然這對於防止意外的相依性很有用，但如果您想要保護輸出流量，並強制所有輸出流量都通過代理伺服器，則應改為依賴輸出閘道。與網路政策結合使用時，您可以強制所有流量或部分子集通過輸出閘道。這可確保即使用戶端意外或惡意繞過其邊車，請求也會被封鎖。

使用 TLS 起源時，在目標規則中設定 TLS 驗證

Istio 提供從邊車代理伺服器或閘道起始 TLS 的功能。這使得傳送純文字 HTTP 流量的應用程式可以透明地「升級」到 HTTPS。

在設定 DestinationRule 的 tls 設定以指定 caCertificates、subjectAltNames 和 sni 欄位時，必須小心。可以透過在 Istiod 上啟用環境變數 VERIFY_CERTIFICATE_AT_CLIENT=true，從系統的憑證儲存區的 CA 憑證自動設定 caCertificate。如果自動使用的作業系統 CA 憑證僅適用於選定的主機，則 Istiod 上的環境變數 VERIFY_CERTIFICATE_AT_CLIENT=false，caCertificates 可以在所需的 DestinationRule 中設定為 system。在 DestinationRule 中指定 caCertificates 將具有優先順序，並且不會使用 OS CA 憑證。預設情況下，輸出流量在 TLS 交握期間不會傳送 SNI。必須在 DestinationRule 中設定 SNI，以確保主機正確處理請求。

例如

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: google-tls
spec:
  host: google.com
  trafficPolicy:
    tls:
      mode: SIMPLE
      caCertificates: /etc/ssl/certs/ca-certificates.crt
      subjectAltNames:
      - "google.com"
      sni: "google.com"

閘道器

在執行 Istio 閘道時，會涉及一些資源

Gateway，控制閘道的連接埠和 TLS 設定。
VirtualService，控制路由邏輯。這些會透過 gateways 欄位中的直接參考以及 Gateway 和 VirtualService 中 hosts 欄位的相互協定，與 Gateway 相關聯。

限制 `Gateway` 建立權限

建議將 Gateway 資源的建立權限限制給受信任的叢集管理員。這可以透過 Kubernetes RBAC 策略或 Open Policy Agent 等工具來實現。

避免過於廣泛的 `hosts` 設定

在可能的情況下，請避免在 Gateway 中使用過於寬泛的 hosts 設定。

例如，此設定將允許任何 VirtualService 綁定到 Gateway，可能會暴露預期之外的網域。

servers:
- port:
    number: 80
    name: http
    protocol: HTTP
  hosts:
  - "*"

應該鎖定此設定，只允許特定的網域或特定的命名空間。

servers:
- port:
    number: 80
    name: http
    protocol: HTTP
  hosts:
  - "foo.example.com" # Allow only VirtualServices that are for foo.example.com
  - "default/bar.example.com" # Allow only VirtualServices in the default namespace that are for bar.example.com
  - "route-namespace/*" # Allow only VirtualServices in the route-namespace namespace for any host

隔離敏感服務

對於敏感服務，可能需要實施更嚴格的物理隔離。例如，您可能希望為敏感的 payments.example.com 運行一個專用的閘道實例，同時為較不敏感的網域（如 blog.example.com 和 store.example.com）使用單一共享的閘道實例。這可以提供更強大的深度防禦，並有助於滿足某些法規遵循的指導原則。

明確停用寬鬆 SNI 主機比對下的所有敏感 http 主機

使用多個 Gateway 在不同的主機上定義相互 TLS 和簡單 TLS 是合理的。例如，針對 SNI 主機 admin.example.com 使用相互 TLS，而針對 SNI 主機 *.example.com 使用簡單 TLS。

kind: Gateway
metadata:
  name: guestgateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - "*.example.com"
    tls:
      mode: SIMPLE
---
kind: Gateway
metadata:
  name: admingateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - admin.example.com
    tls:
      mode: MUTUAL

如果需要上述設定，強烈建議在附加到 *.example.com 的 VirtualService 中明確停用 HTTP 主機 admin.example.com。原因是目前底層的 Envoy 代理不要求 HTTP 1 標頭 Host 或 HTTP 2 偽標頭 :authority 遵循 SNI 約束，攻擊者可以重用訪客 SNI TLS 連線來存取管理 VirtualService。HTTP 回應碼 421 是專為此 Host SNI 不符而設計的，可用於實現停用。

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: disable-sensitive
spec:
  hosts:
  - "admin.example.com"
  gateways:
  - guestgateway
  http:
  - match:
    - uri:
        prefix: /
    fault:
      abort:
        percentage:
          value: 100
        httpStatus: 421
    route:
    - destination:
        port:
          number: 8000
        host: dest.default.cluster.local

通訊協定偵測

Istio 將自動判斷它所看到的流量協定。為了避免意外或故意的誤檢測，這可能會導致意外的流量行為，建議盡可能明確宣告協定。

CNI

為了透明地捕獲所有流量，Istio 依賴於由 istio-init initContainer 配置的 iptables 規則。這對 Pod 添加了一個要求，即 NET_ADMIN 和 NET_RAW capabilities 對 Pod 可用。

為了減少授予 Pod 的權限，Istio 提供了一個CNI 外掛程式，它消除了此要求。

使用強化的 Docker 映像檔

Istio 的預設 Docker 映像，包括由控制平面、閘道和 Sidecar 代理執行的映像，都是基於 ubuntu 的。這提供了各種工具，例如 bash 和 curl，這是在便利性和增加攻擊面之間進行權衡。

Istio 還提供了一個基於無發行版映像的較小映像，它可以減少映像中的依賴項。

發布與安全政策

為了確保您的叢集具有已知漏洞的最新安全修補程式，請務必使用 Istio 的最新修補程式版本，並確保您使用的是仍在接收安全修補程式的受支援版本。

偵測無效的設定

雖然 Istio 在資源建立時會進行驗證，但這些檢查無法捕捉到所有會阻止設定在網格中分發的問題。這可能會導致套用意外被忽略的策略，從而導致意外的結果。

在套用設定之前或之後執行 istioctl analyze，以確保它是有效的。
監視控制平面是否有被拒絕的設定。這些會透過 pilot_total_xds_rejects 指標以及記錄來公開。
測試您的設定，以確保它產生預期的結果。對於安全策略，執行正向和負向測試以確保您不會意外地限制過多或過少的流量是很有用的。

避免使用 Alpha 和實驗性功能

所有 Istio 功能和 API 都被分配一個功能狀態，定義其穩定性、棄用策略和安全策略。

由於 Alpha 和實驗性功能沒有那麼強的安全保證，因此建議盡可能避免使用它們。在這些功能中發現的安全問題可能不會立即修復，或者不遵循我們的標準安全漏洞處理流程。

若要判斷叢集中使用的功能的功能狀態，請參閱Istio 功能清單。

鎖定連接埠

Istio 配置了各種連接埠，可以鎖定以提高安全性。

控制平面

Istiod 預設會公開一些未經身分驗證的純文字連接埠，以方便使用。如果需要，可以關閉這些連接埠。

連接埠 8080 公開偵錯介面，該介面提供對叢集狀態的各種詳細資訊的讀取權限。可以透過在 Istiod 上設定環境變數 ENABLE_DEBUG_ON_HTTP=false 來停用此介面。警告：許多 istioctl 命令都依賴此介面，如果停用此介面，這些命令將無法運作。
連接埠 15010 透過純文字公開 XDS 服務。可以透過將 --grpcAddr="" 標誌新增到 Istiod 部署來停用此連接埠。注意：高度敏感的服務（例如憑證簽署和分發服務）永遠不會透過純文字提供。

資料平面

代理公開各種連接埠。外部公開的是連接埠 15090（遙測）和連接埠 15021（健康檢查）。連接埠 15020 和 15000 提供偵錯端點。這些僅透過 localhost 公開。因此，與代理在同一 Pod 中執行的應用程式具有存取權；Sidecar 和應用程式之間沒有信任邊界。

設定第三方服務帳戶權杖

為了向 Istio 控制平面進行身分驗證，Istio 代理將使用服務帳戶權杖。Kubernetes 支援兩種形式的權杖

第三方權杖，具有限定的受眾和到期時間。
第一方權杖，沒有到期時間，並且掛載到所有 Pod 中。

由於第一方權杖的屬性不太安全，因此 Istio 將預設使用第三方權杖。但是，並非所有 Kubernetes 平台上都啟用了此功能。

如果您使用 istioctl 進行安裝，則會自動偵測到支援。也可以手動執行此操作，並透過傳遞 --set values.global.jwtPolicy=third-party-jwt 或 --set values.global.jwtPolicy=first-party-jwt 進行配置。

若要判斷您的叢集是否支援第三方權杖，請尋找 TokenRequest API。如果此 API 沒有傳回回應，則表示不支援此功能。

$ kubectl get --raw /api/v1 | jq '.resources[] | select(.name | index("serviceaccounts/token"))'
{
    "name": "serviceaccounts/token",
    "singularName": "",
    "namespaced": true,
    "group": "authentication.k8s.io",
    "version": "v1",
    "kind": "TokenRequest",
    "verbs": [
        "create"
    ]
}

雖然大多數雲端供應商現在都支援此功能，但在 Kubernetes 1.20 之前，許多本機開發工具和自訂安裝可能不支援。若要啟用此功能，請參閱Kubernetes 文件。

設定下游連線的限制

預設情況下，Istio（和 Envoy）對下游連線的數量沒有限制。惡意行為者可以利用此漏洞（請參閱安全公告 2020-007）。若要解決此問題，您必須為您的環境配置適當的連線限制。

設定 `global_downstream_max_connections` 值

可以在安裝期間提供以下配置

meshConfig:
  defaultConfig:
    runtimeValues:
      "overload.global_downstream_max_connections": "100000"

安全最佳實務

相互 TLS

授權原則

更安全的授權原則模式

使用預設拒絕模式

使用 ALLOW-with-positive-matching 和 DENY-with-negative-match 模式

了解授權原則中的路徑正規化

關於設定路徑正規化選項的指南

案例 1：您完全不需要正規化

案例 2：您需要正規化，但不確定要使用哪個正規化選項

案例 3：您需要不受支援的正規化選項

客製化您系統上的路徑正規化

設定範例

如何設定

不受支援的正規化的緩解措施

自訂正規化邏輯

範例自訂正規化 (案例正規化)

撰寫主機比對原則

專業的 Web 應用程式防火牆 (WAF)

Istio 的功能要求

已知限制

不支援伺服器優先 TCP 通訊協定

了解流量擷取限制

使用 NetworkPolicy 的深度防禦

保護出口流量

使用 TLS 起源時，在目標規則中設定 TLS 驗證

閘道器

限制 Gateway 建立權限

避免過於廣泛的 hosts 設定

隔離敏感服務

明確停用寬鬆 SNI 主機比對下的所有敏感 http 主機

通訊協定偵測

CNI

使用強化的 Docker 映像檔

發布與安全政策

偵測無效的設定

避免使用 Alpha 和實驗性功能

鎖定連接埠

控制平面

資料平面

設定第三方服務帳戶權杖

設定下游連線的限制

設定 global_downstream_max_connections 值

使用 `ALLOW-with-positive-matching` 和 `DENY-with-negative-match` 模式

使用 `NetworkPolicy` 的深度防禦

限制 `Gateway` 建立權限

避免過於廣泛的 `hosts` 設定

設定 `global_downstream_max_connections` 值