安全性

 23 分鐘閱讀  

將單體應用程式分解為原子服務可帶來各種好處，包括更好的靈活性、更好的可擴展性和更好的服務重用能力。然而，微服務也有特定的安全需求

  • 為了防禦中間人攻擊，它們需要流量加密。
  • 為了提供彈性的服務存取控制，它們需要相互 TLS 和精細的存取原則。
  • 為了確定誰在什麼時間做了什麼，它們需要稽核工具。

Istio 安全性提供了全面的安全解決方案來解決這些問題。本頁概述了如何使用 Istio 安全功能來保護您的服務，無論您在何處執行它們。特別是，Istio 安全性可降低內部和外部針對您的資料、端點、通訊和平台的威脅。

Security overview
安全性概述

Istio 的安全功能提供強大的身分識別、強大的政策、透明的 TLS 加密，以及身份驗證、授權和稽核 (AAA) 工具，以保護您的服務和資料。Istio 安全性的目標是：

  • 預設安全：無需變更應用程式程式碼和基礎架構
  • 縱深防禦：與現有的安全系統整合，以提供多層防禦
  • 零信任網路：在不信任的網路上建立安全解決方案

請造訪我們的相互 TLS 遷移文件，開始將 Istio 安全功能與您部署的服務一起使用。請造訪我們的安全任務，以取得使用安全功能的詳細說明。

高階架構

Istio 中的安全性涉及多個元件

控制平面處理來自 API 伺服器的組態，並在資料平面中設定 PEP。PEP 是使用 Envoy 實作。下圖顯示了架構。

Security Architecture
安全架構

在以下章節中，我們將詳細介紹 Istio 安全功能。

Istio 身分

身分識別是任何安全基礎架構的基本概念。在工作負載對工作負載通訊開始時，雙方必須交換包含其身分資訊的憑證，以進行相互驗證。在用戶端，伺服器的身分會根據安全命名資訊進行檢查，以查看其是否為工作負載的授權執行者。在伺服器端，伺服器可以根據授權政策，判斷用戶端可以存取哪些資訊、稽核誰在何時存取了哪些資訊、根據用戶端使用的工作負載向其收費，並拒絕任何未付帳單的用戶端存取工作負載。

Istio 身分識別模型使用第一級的 service identity 來判斷請求來源的身分。此模型允許服務身分具有極大的彈性和細微性，以表示人類使用者、個別工作負載或工作負載群組。在沒有服務身分的平台上，Istio 可以使用其他可以將工作負載執行個體分組的身分，例如服務名稱。

以下清單顯示您可以在不同平台上使用的服務身分範例

  • Kubernetes：Kubernetes 服務帳戶
  • GCE：GCP 服務帳戶
  • 內部部署 (非 Kubernetes)：使用者帳戶、自訂服務帳戶、服務名稱、Istio 服務帳戶或 GCP 服務帳戶。自訂服務帳戶是指現有的服務帳戶，就像客戶的身分識別目錄所管理的身分一樣。

身分和憑證管理

Istio 使用 X.509 憑證安全地為每個工作負載佈建強大的身分識別。與每個 Envoy Proxy 一起執行的 Istio 代理程式與 istiod 協同運作，以大規模自動化金鑰和憑證輪換。下圖顯示了身分佈建流程。

Identity Provisioning Workflow
身分佈建工作流程

Istio 透過以下流程佈建金鑰和憑證

  1. istiod 提供 gRPC 服務來處理憑證簽署請求 (CSR)。
  2. 啟動時，Istio 代理程式會建立私密金鑰和 CSR，然後將包含其憑證的 CSR 傳送至 istiod 進行簽署。
  3. istiod 中的 CA 會驗證 CSR 中包含的憑證。驗證成功後，它會簽署 CSR 以產生憑證。
  4. 當工作負載啟動時，Envoy 會透過Envoy 秘密探索服務 (SDS) API，從同一個容器中的 Istio 代理程式請求憑證和金鑰。
  5. Istio 代理程式會透過 Envoy SDS API，將從 istiod 收到的憑證和私密金鑰傳送至 Envoy。
  6. Istio 代理程式會監控工作負載憑證的到期時間。上述流程會定期重複執行，以進行憑證和金鑰輪換。

身分驗證

Istio 提供兩種身分驗證類型

  • 對等身分驗證：用於服務對服務的身分驗證，以驗證進行連線的用戶端。Istio 提供相互 TLS 作為傳輸身分驗證的完整堆疊解決方案，可以在不變更服務程式碼的情況下啟用。此解決方案

    • 為每個服務提供代表其角色的強大身分，以實現跨叢集和雲端的互通性。
    • 保護服務對服務的通訊。
    • 提供金鑰管理系統，以自動化金鑰和憑證的產生、散發和輪換。

  • 請求身分驗證：用於終端使用者身分驗證，以驗證附加至請求的憑證。Istio 使用 JSON Web Token (JWT) 驗證和簡化的開發人員體驗，透過自訂身分驗證提供者或任何 OpenID Connect 提供者 (例如) 啟用請求層級的身分驗證

在所有情況下，Istio 都會透過自訂 Kubernetes API 將身分驗證政策儲存在 Istio 組態儲存中。Istiod 會讓每個 Proxy 的政策保持最新狀態，並在適當情況下保持金鑰最新狀態。此外，Istio 支援寬容模式的身分驗證，以協助您了解政策變更在強制執行前會如何影響您的安全性態勢。

相互 TLS 身分驗證

Istio 會透過用戶端和伺服器端的 PEP 通道傳輸服務對服務的通訊，這些 PEP 是以Envoy Proxy 實作。當工作負載使用相互 TLS 身分驗證將請求傳送至另一個工作負載時，請求會按如下方式處理

  1. Istio 會將來自用戶端的輸出流量重新路由至用戶端的本機 Sidecar Envoy。
  2. 用戶端 Sidecar Envoy 會與伺服器端 Sidecar Envoy 開始相互 TLS 交握。在交握期間，用戶端 Sidecar Envoy 也會執行安全命名檢查，以驗證伺服器憑證中提供的服務帳戶是否獲授權執行目標服務。
  3. 用戶端 Sidecar Envoy 和伺服器端 Sidecar Envoy 會建立相互 TLS 連線，而 Istio 會將流量從用戶端 Sidecar Envoy 轉送至伺服器端 Sidecar Envoy。
  4. 伺服器端 Envoy 會授權請求。如果已授權，則會透過本機 TCP 連線將流量轉送至後端服務。

Istio 會將 TLSv1_2 設定為用戶端和伺服器的最低 TLS 版本，並使用下列加密套件

  • ECDHE-ECDSA-AES256-GCM-SHA384

  • ECDHE-RSA-AES256-GCM-SHA384

  • ECDHE-ECDSA-AES128-GCM-SHA256

  • ECDHE-RSA-AES128-GCM-SHA256

  • AES256-GCM-SHA384

  • AES128-GCM-SHA256

寬容模式

Istio 相互 TLS 具有寬容模式，允許服務同時接受純文字流量和相互 TLS 流量。此功能極大地改善了相互 TLS 的加入體驗。

許多與非 Istio 伺服器通訊的非 Istio 用戶端，對於想要將該伺服器遷移到啟用相互 TLS 的 Istio 的運算子來說，是一個問題。通常，運算子無法同時為所有用戶端安裝 Istio Sidecar，甚至在某些用戶端上沒有權限執行此操作。即使在伺服器上安裝 Istio Sidecar 後，運算子也無法在不中斷現有通訊的情況下啟用相互 TLS。

在啟用寬容模式的情況下，伺服器會接受純文字和相互 TLS 流量。此模式為加入流程提供了更大的彈性。伺服器安裝的 Istio Sidecar 會立即接收相互 TLS 流量，而不會中斷現有的純文字流量。因此，運算子可以逐步安裝和設定用戶端的 Istio Sidecar，以傳送相互 TLS 流量。用戶端的設定完成後，運算子可以將伺服器設定為僅限相互 TLS 模式。如需更多資訊，請造訪相互 TLS 遷移教學課程。

安全命名

伺服器身分會編碼在憑證中，但服務名稱會透過探索服務或 DNS 擷取。安全命名資訊會將伺服器身分對應至服務名稱。身分 A 對應至服務名稱 B 表示「A 獲授權執行服務 B」。控制平面會監看 apiserver、產生安全命名對應，並安全地將其散發至 PEP。下列範例說明為什麼安全命名在身分驗證中至關重要。

假設執行 datastore 服務的合法伺服器僅使用 infra-team 身分。惡意使用者具有 test-team 身分的憑證和金鑰。惡意使用者打算假冒服務，以檢查從用戶端傳送的資料。惡意使用者使用 test-team 身分的憑證和金鑰部署偽造的伺服器。假設惡意使用者成功劫持 (透過 DNS 詐騙、BGP/路由劫持、ARP 詐騙等) 傳送至 datastore 的流量，並將其重新導向至偽造的伺服器。

當用戶端呼叫 datastore 服務時，它會從伺服器的憑證中擷取 test-team 身分，並使用安全命名資訊檢查是否允許 test-team 執行 datastore。用戶端會偵測到不允許 test-team 執行 datastore 服務，並且身分驗證失敗。

請注意，對於非 HTTP/HTTPS 流量，安全命名不會防止 DNS 詐騙，在這種情況下，攻擊者會修改服務的目的地 IP。由於 TCP 流量不包含 Host 資訊，而 Envoy 只能依賴目的地 IP 進行路由，因此 Envoy 可能會將流量路由至被劫持 IP 上的服務。即使在用戶端 Sidecar Envoy 收到流量之前，也可能發生此 DNS 詐騙。

身分驗證架構

您可以使用對等和請求身分驗證政策，在 Istio 網格中為接收請求的工作負載指定身分驗證要求。網格運算子會使用 .yaml 檔案來指定政策。部署後，這些政策會儲存在 Istio 組態儲存中。Istio 控制器會監看組態儲存。

一旦發生任何政策變更，新政策就會轉換為適當的組態，告知 PEP 如何執行所需的身分驗證機制。控制平面可能會擷取公鑰，並將其附加至組態以進行 JWT 驗證。或者，Istiod 提供 Istio 系統管理之金鑰和憑證的路徑，並將其安裝到應用程式 Pod 中以進行相互 TLS。您可以在身分識別和憑證管理章節中找到更多資訊。

Istio 會以非同步方式將組態傳送至目標端點。一旦 Proxy 收到組態，新的身分驗證要求就會立即在該 Pod 上生效。

用戶端服務 (即傳送請求的服務) 負責遵循必要的身分驗證機制。對於請求身分驗證，應用程式負責取得 JWT 憑證並將其附加至請求。對於對等身分驗證，Istio 會自動將兩個 PEP 之間的全部流量升級為相互 TLS。如果身分驗證政策停用相互 TLS 模式，則 Istio 會繼續在 PEP 之間使用純文字。若要覆寫此行為，請使用目的地規則明確停用相互 TLS 模式。您可以在相互 TLS 身分驗證章節中找到更多關於相互 TLS 如何運作的資訊。

Authentication Architecture
身分驗證架構

Istio 會以兩種身分驗證類型輸出身分識別，以及憑證中的其他宣告 (如果適用)，至下一層：授權。

身分驗證原則

本節提供有關 Istio 身份驗證策略如何運作的更多詳細資訊。如同您在架構章節中記得的，身份驗證策略適用於服務接收的請求。若要在相互 TLS 中指定客戶端身份驗證規則，您需要在 DestinationRule 中指定 TLSSettings。您可以在我們的 TLS 設定參考文件中找到更多資訊。

如同其他 Istio 設定，您可以在 .yaml 檔案中指定身份驗證策略。您可以使用 kubectl 部署策略。以下範例身份驗證策略指定具有 app:reviews 標籤的工作負載的傳輸身份驗證必須使用相互 TLS。

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: "example-peer-policy"
  namespace: "foo"
spec:
  selector:
    matchLabels:
      app: reviews
  mtls:
    mode: STRICT

原則儲存

Istio 將網格範圍的策略儲存在根命名空間中。這些策略具有空的選擇器，適用於網格中的所有工作負載。具有命名空間範圍的策略儲存在對應的命名空間中。它們僅適用於其命名空間內的工作負載。如果您設定 selector 欄位，則身份驗證策略僅適用於符合您設定條件的工作負載。

對等身份驗證策略和請求身份驗證策略會分別依類型儲存為 PeerAuthentication 和 RequestAuthentication。

選取器欄位

對等身份驗證策略和請求身份驗證策略會使用 selector 欄位來指定策略套用的工作負載標籤。以下範例顯示套用至具有 app:product-page 標籤的工作負載之策略的選擇器欄位。

selector:
  matchLabels:
    app: product-page

如果您沒有為 selector 欄位提供值，Istio 會將該策略與策略儲存範圍內的所有工作負載比對。因此，selector 欄位可協助您指定策略的範圍。

  • 網格範圍策略：為根命名空間指定且沒有或具有空的 selector 欄位的策略。
  • 命名空間範圍策略：為非根命名空間指定且沒有或具有空的 selector 欄位的策略。
  • 工作負載特定策略：在一般命名空間中定義且具有非空選擇器欄位的策略。

對等身份驗證策略和請求身份驗證策略對於 selector 欄位遵循相同的階層原則，但 Istio 會以略有不同的方式組合並套用它們。

每個網格只能有一個網格範圍的對等身份驗證策略，每個命名空間只能有一個命名空間範圍的對等身份驗證策略。當您為同一個網格或命名空間設定多個網格範圍或命名空間範圍的對等身份驗證策略時，Istio 會忽略較新的策略。當有多個工作負載特定的對等身份驗證策略符合時，Istio 會選擇最舊的策略。

Istio 會依以下順序，針對每個工作負載套用最窄的符合策略

  1. 工作負載特定
  2. 命名空間範圍
  3. 網格範圍

Istio 可以組合所有符合的請求身份驗證策略，讓它們如同來自單一請求身份驗證策略般運作。因此，您可以在網格或命名空間中擁有多個網格範圍或命名空間範圍的策略。但是，仍然建議避免使用多個網格範圍或命名空間範圍的請求身份驗證策略。

對等身分驗證

對等身份驗證策略會指定 Istio 在目標工作負載上強制執行的相互 TLS 模式。支援以下模式：

  • PERMISSIVE：工作負載會接受相互 TLS 和純文字流量。此模式在遷移期間最有用，因為沒有 Sidecar 的工作負載無法使用相互 TLS。一旦使用 Sidecar 注入遷移工作負載後，您應該將模式切換為 STRICT。
  • STRICT：工作負載只接受相互 TLS 流量。
  • DISABLE：相互 TLS 已停用。從安全的角度來看，除非您提供自己的安全性解決方案，否則不應使用此模式。

當模式未設定時，會繼承父範圍的模式。具有未設定模式的網格範圍對等身份驗證策略預設會使用 PERMISSIVE 模式。

以下對等身份驗證策略要求命名空間 foo 中的所有工作負載都使用相互 TLS。

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: "example-policy"
  namespace: "foo"
spec:
  mtls:
    mode: STRICT

透過工作負載特定的對等身份驗證策略，您可以為不同的連接埠指定不同的相互 TLS 模式。您只能使用工作負載已聲明用於連接埠範圍相互 TLS 設定的連接埠。以下範例會停用 app:example-app 工作負載的連接埠 80 上的相互 TLS，並將命名空間範圍的對等身份驗證策略的相互 TLS 設定用於所有其他連接埠。

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: "example-workload-policy"
  namespace: "foo"
spec:
  selector:
     matchLabels:
       app: example-app
  portLevelMtls:
    80:
      mode: DISABLE

上述對等身份驗證策略只有在以下服務設定將來自 example-app 工作負載的請求繫結至 example-service 的連接埠 80 時才會運作。

apiVersion: v1
kind: Service
metadata:
  name: example-service
  namespace: foo
spec:
  ports:
  - name: http
    port: 8000
    protocol: TCP
    targetPort: 80
  selector:
    app: example-app

請求身分驗證

請求身份驗證策略會指定驗證 JSON Web 權杖 (JWT) 所需的值。這些值包括 (但不限於) 以下項目：

  • 權杖在請求中的位置
  • 請求的發行者
  • 公開 JSON Web 金鑰集 (JWKS)

Istio 會根據請求身份驗證策略中的規則檢查提供的權杖 (如果有的話)，並拒絕包含無效權杖的請求。當請求不攜帶任何權杖時，預設會接受這些請求。若要拒絕沒有權杖的請求，請提供授權規則，以指定特定作業的限制，例如路徑或動作。

如果每個請求都使用唯一的位置，則請求身份驗證策略可以指定多個 JWT。當有多個策略符合工作負載時，Istio 會將所有規則組合，就好像它們被指定為單一策略一樣。此行為對於編寫程式來讓工作負載接受來自不同提供者的 JWT 非常有用。但是，不支援具有多個有效 JWT 的請求，因為此類請求的輸出主體未定義。

主體

當您使用對等身份驗證策略和相互 TLS 時，Istio 會將身分從對等身份驗證提取到 source.principal 中。同樣地，當您使用請求身份驗證策略時，Istio 會將 JWT 的身分指派給 request.auth.principal。使用這些主體來設定授權策略並作為遙測輸出。

更新身分驗證原則

您可以隨時變更身份驗證策略，而 Istio 會幾乎即時地將新策略推送至工作負載。但是，Istio 無法保證所有工作負載都同時收到新策略。以下建議有助於在更新身份驗證策略時避免中斷：

  • 當將模式從 DISABLE 變更為 STRICT 或反向變更時，請使用 PERMISSIVE 模式的中繼對等身份驗證策略。當所有工作負載都成功切換至所需的模式時，您可以套用最終模式的策略。您可以使用 Istio 遙測來驗證工作負載是否已成功切換。
  • 當從一個 JWT 遷移請求身份驗證策略至另一個 JWT 時，請將新 JWT 的規則新增至策略，而不要移除舊規則。然後，工作負載會接受兩種 JWT，而且當所有流量都切換至新的 JWT 時，您可以移除舊規則。但是，每個 JWT 都必須使用不同的位置。

授權

Istio 的授權功能可為網格中的工作負載提供網格範圍、命名空間範圍和工作負載範圍的存取控制。此控制層級提供以下優點：

  • 工作負載對工作負載及終端使用者對工作負載授權。
  • 簡單的 API：它包含單一的 AuthorizationPolicy CRD，易於使用和維護。
  • 彈性語意：操作員可以定義 Istio 屬性的自訂條件，並使用 CUSTOM、DENY 和 ALLOW 動作。
  • 高效能：Istio 授權 (ALLOW 和 DENY) 是在 Envoy 上以原生方式強制執行。
  • 高度相容性：原生支援 gRPC、HTTP、HTTPS 和 HTTP/2，以及任何純 TCP 協定。

授權架構

授權策略會在伺服器端 Envoy Proxy 中強制執行對輸入流量的存取控制。每個 Envoy Proxy 都會執行一個授權引擎，該引擎會在執行階段授權請求。當請求傳送到 Proxy 時，授權引擎會根據目前的授權策略評估請求內容，並傳回授權結果，即 ALLOW 或 DENY。操作員會使用 .yaml 檔案指定 Istio 授權策略。

Authorization Architecture
授權架構

隱式啟用

您不需要明確啟用 Istio 的授權功能；它們在安裝後即可使用。若要對工作負載強制執行存取控制，您需要套用授權策略。

對於未套用授權策略的工作負載，Istio 允許所有請求。

授權策略支援 ALLOW、DENY 和 CUSTOM 動作。您可以根據需要套用多個具有不同動作的策略，以保護對工作負載的存取。

Istio 會依以下順序，以分層方式檢查符合的策略：CUSTOM、DENY，然後是 ALLOW。對於每種類型的動作，Istio 會先檢查是否有套用該動作的策略，然後檢查請求是否符合該策略的規格。如果請求不符合其中一個層級的策略，檢查將會繼續到下一層級。

下圖詳細顯示了策略的優先順序

Authorization Policy Precedence
授權策略優先順序

當您將多個授權策略套用到相同的工作負載時，Istio 會累加式套用它們。

授權原則

若要設定授權策略，您需要建立 AuthorizationPolicy 自訂資源。授權策略包括一個選擇器、一個動作和一個規則清單。

  • selector 欄位會指定策略的目標。
  • action 欄位會指定是否允許或拒絕請求。
  • rules 會指定何時觸發動作。
    • rules 中的 from 欄位會指定請求的來源。
    • rules 中的 to 欄位會指定請求的作業。
    • when 欄位會指定套用規則所需的條件。

以下範例顯示一個授權策略，該策略允許兩個來源 (cluster.local/ns/default/sa/curl 服務帳戶和 dev 命名空間) 在傳送的請求具有有效 JWT 權杖時，存取 foo 命名空間中具有 app: httpbin 和 version: v1 標籤的工作負載。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
 name: httpbin
 namespace: foo
spec:
 selector:
   matchLabels:
     app: httpbin
     version: v1
 action: ALLOW
 rules:
 - from:
   - source:
       principals: ["cluster.local/ns/default/sa/curl"]
   - source:
       namespaces: ["dev"]
   to:
   - operation:
       methods: ["GET"]
   when:
   - key: request.auth.claims[iss]
     values: ["https://#"]

以下範例顯示一個授權策略，該策略會拒絕來源不是 foo 命名空間的請求。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
 name: httpbin-deny
 namespace: foo
spec:
 selector:
   matchLabels:
     app: httpbin
     version: v1
 action: DENY
 rules:
 - from:
   - source:
       notNamespaces: ["foo"]

拒絕策略的優先順序高於允許策略。如果請求符合拒絕策略，則符合允許策略的請求可能會被拒絕。Istio 會先評估拒絕策略，以確保允許策略無法繞過拒絕策略。

原則目標

您可以使用 metadata/namespace 欄位和選用的 selector 欄位來指定策略的範圍或目標。策略會套用至 metadata/namespace 欄位中的命名空間。如果將其值設定為根命名空間，則該策略會套用至網格中的所有命名空間。根命名空間的值是可設定的，預設值為 istio-system。如果設定為任何其他命名空間，則該策略只會套用至指定的命名空間。

您可以使用 selector 欄位來進一步限制策略套用至特定的工作負載。selector 使用標籤來選擇目標工作負載。選擇器包含 {key: value} 配對清單，其中 key 是標籤的名稱。如果未設定，則授權策略會套用至與授權策略相同的命名空間中的所有工作負載。

舉例來說，allow-read 策略允許對具有 app: products 標籤且位於 default 命名空間中的工作負載進行 "GET" 和 "HEAD" 存取。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-read
  namespace: default
spec:
  selector:
    matchLabels:
      app: products
  action: ALLOW
  rules:
  - to:
    - operation:
         methods: ["GET", "HEAD"]

值比對

授權策略中的大多數欄位都支援以下所有比對模式

  • 完全比對：字串完全比對。
  • 前綴比對：以 "*" 結尾的字串。例如，"test.abc.*" 比對 "test.abc.com"、"test.abc.com.cn"、"test.abc.org" 等。
  • 後綴比對：以 "*" 開頭的字串。例如，"*.abc.com" 比對 "eng.abc.com"、"test.eng.abc.com" 等。
  • 存在比對：* 用於指定任何非空值。若要指定欄位必須存在，請使用 fieldname: ["*"] 格式。這與不指定欄位不同，後者表示比對任何值，包括空值。

有一些例外情況。例如，以下欄位僅支援完全比對

  • when 區段下的 key 欄位
  • source 區段下的 ipBlocks 欄位
  • to 區段下的 ports 欄位

以下範例策略允許存取具有 /test/* 前綴或 */info 後綴的路徑。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: tester
  namespace: default
spec:
  selector:
    matchLabels:
      app: products
  action: ALLOW
  rules:
  - to:
    - operation:
        paths: ["/test/*", "*/info"]

排除比對

若要比對 when 欄位中的 notValues、source 欄位中的 notIpBlocks、to 欄位中的 notPorts 等負面條件，Istio 支援排除比對。以下範例需要有效的請求主體（從 JWT 身份驗證衍生而來），如果請求路徑不是 /healthz。因此，此策略將對 /healthz 路徑的請求排除在 JWT 身份驗證之外。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: disable-jwt-for-healthz
  namespace: default
spec:
  selector:
    matchLabels:
      app: products
  action: ALLOW
  rules:
  - to:
    - operation:
        notPaths: ["/healthz"]
    from:
    - source:
        requestPrincipals: ["*"]

以下範例拒絕沒有請求主體的請求存取 /admin 路徑。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: enable-jwt-for-admin
  namespace: default
spec:
  selector:
    matchLabels:
      app: products
  action: DENY
  rules:
  - to:
    - operation:
        paths: ["/admin"]
    from:
    - source:
        notRequestPrincipals: ["*"]

allow-nothing、deny-all 和 allow-all 原則

以下範例顯示一個不比對任何內容的 ALLOW 策略。如果沒有其他 ALLOW 策略，則由於「預設拒絕」的行為，請求將始終被拒絕。

請注意，「預設拒絕」行為僅在工作負載至少有一個具有 ALLOW 動作的授權策略時才會生效。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-nothing
spec:
  action: ALLOW
  # the rules field is not specified, and the policy will never match.

以下範例顯示一個明確拒絕所有存取的 DENY 策略。即使有另一個 ALLOW 策略允許請求，它也總是會拒絕請求，因為 DENY 策略的優先順序高於 ALLOW 策略。如果您想暫時停用對工作負載的所有存取，這會很有用。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-all
spec:
  action: DENY
  # the rules field has an empty rule, and the policy will always match.
  rules:
  - {}

以下範例顯示一個允許完全存取工作負載的 ALLOW 策略。它會使其他 ALLOW 策略失效，因為它總是會允許請求。如果您想暫時公開對工作負載的完全存取，這可能會很有用。請注意，由於 CUSTOM 和 DENY 策略，請求仍然可能被拒絕。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-all
spec:
  action: ALLOW
  # This matches everything.
  rules:
  - {}

自訂條件

您也可以使用 when 區段來指定其他條件。例如，以下 AuthorizationPolicy 定義包含一個條件，即 request.headers[version] 要么是 "v1" 要么是 "v2"。在這種情況下，索引鍵是 request.headers[version]，它是 Istio 屬性 request.headers 中的一個條目，該屬性是一個映射。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
 name: httpbin
 namespace: foo
spec:
 selector:
   matchLabels:
     app: httpbin
     version: v1
 action: ALLOW
 rules:
 - from:
   - source:
       principals: ["cluster.local/ns/default/sa/curl"]
   to:
   - operation:
       methods: ["GET"]
   when:
   - key: request.headers[version]
     values: ["v1", "v2"]

條件支援的 key 值列在條件頁面上。

已驗證和未驗證的身分

如果您希望讓工作負載公開存取，您需要將 source 區段留空。這允許來自所有（經過身份驗證和未經身份驗證）使用者和工作負載的來源，例如：

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
 name: httpbin
 namespace: foo
spec:
 selector:
   matchLabels:
     app: httpbin
     version: v1
 action: ALLOW
 rules:
 - to:
   - operation:
       methods: ["GET", "POST"]

若要僅允許經過身份驗證的使用者，請將 principals 設定為 "*"，例如：

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
 name: httpbin
 namespace: foo
spec:
 selector:
   matchLabels:
     app: httpbin
     version: v1
 action: ALLOW
 rules:
 - from:
   - source:
       principals: ["*"]
   to:
   - operation:
       methods: ["GET", "POST"]

在純 TCP 協定上使用 Istio 授權

Istio 授權支援使用任何純 TCP 協定的工作負載，例如 MongoDB。在這種情況下，您可以像對 HTTP 工作負載一樣設定授權策略。不同之處在於某些欄位和條件僅適用於 HTTP 工作負載。這些欄位包括：

  • 授權策略物件的 source 區段中的 request_principals 欄位
  • 授權策略物件的 operation 區段中的 hosts、methods 和 paths 欄位

支援的條件列在條件頁面中。如果您為 TCP 工作負載使用任何僅適用於 HTTP 的欄位，Istio 將會忽略授權策略中僅適用於 HTTP 的欄位。

假設您在連接埠 27017 上有一個 MongoDB 服務，以下範例設定一個授權策略，只允許 Istio 網格中的 bookinfo-ratings-v2 服務存取 MongoDB 工作負載。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: mongodb-policy
  namespace: default
spec:
 selector:
   matchLabels:
     app: mongodb
 action: ALLOW
 rules:
 - from:
   - source:
       principals: ["cluster.local/ns/default/sa/bookinfo-ratings-v2"]
   to:
   - operation:
       ports: ["27017"]

對相互 TLS 的依賴性

Istio 使用相互 TLS 安全地將一些資訊從客戶端傳遞到伺服器。在使用授權策略中的以下任何欄位之前，必須啟用相互 TLS

  • source 區段下的 principals 和 notPrincipals 欄位
  • source 區段下的 namespaces 和 notNamespaces 欄位
  • source.principal 自訂條件
  • source.namespace 自訂條件

請注意，強烈建議始終在 PeerAuthentication 中使用嚴格相互 TLS 模式來使用這些欄位，以避免在使用寬鬆相互 TLS 模式的純文字流量時，發生潛在的意外請求拒絕或策略繞過。

如果您無法啟用嚴格相互 TLS 模式，請查看安全性建議以獲取更多詳細資訊和替代方案。

了解更多

在了解基本概念之後，還有更多資源可以查閱

此資訊是否實用？
您是否有任何改進建議？

感謝您的回饋！