授權政策總覽

<0x0 Google Cloud 詳情請參閱 Cloud Service Mesh 總覽。

單體式應用程式可能在單一位置執行，但全球分散式微服務應用程式會跨越網路界線進行呼叫。這表示應用程式的進入點變多，惡意攻擊的機會也隨之增加。此外，由於 Kubernetes Pod 的 IP 位址是暫時性的，傳統的 IP 位址型防火牆規則不足以確保工作負載之間的存取安全。在微服務架構中，需要採用新的安全防護方法。Cloud Service Mesh 以 Kubernetes 服務帳戶和 Istio 安全性政策等安全功能為基礎，提供更多功能，協助您保護應用程式。

本頁提供應用程式運算子自訂資源 (CR) 的總覽。AuthorizationPolicy授權政策可讓您在應用程式 (L7) 和傳輸 (L3/4) 層級，對工作負載啟用存取權控管。您可以設定授權政策來指定權限，也就是允許這項服務或使用者執行的動作。

授權政策

根據預設，網格中服務之間 (以及使用者與服務之間) 的要求都會獲准。您可以使用 AuthorizationPolicy CR 為工作負載定義精細的政策。套用授權政策後，Cloud Service Mesh 會將政策分配給補充 Proxy。當要求進入工作負載時，Sidecar Proxy 會檢查授權政策，判斷是否應允許或拒絕要求。

如要瞭解平台支援的 AuthorizationPolicy CR 欄位，請參閱「支援的功能」。

政策範圍

您可以將政策套用至整個服務網格、命名空間或個別工作負載。

• 如要套用網格範圍的政策，請在 metadata:namespace 欄位中指定根命名空間 istio-system：

  apiVersion: "security.istio.io/v1beta1"
  kind: "AuthorizationPolicy"
  metadata:
    name: "mesh-wide"
    namespace: istio-system
  spec:
  ...
  

• 如要將政策套用至命名空間，請在 metadata:namespace 欄位中指定命名空間：

  apiVersion: "security.istio.io/v1beta1"
  kind: "AuthorizationPolicy"
  metadata:
    name: "currencyservice"
    namespace: currencyservice
  spec:
  ...
  

• 如要將政策限制為特定工作負載，請加入 selector 欄位。

  apiVersion: "security.istio.io/v1beta1"
  kind: "AuthorizationPolicy"
  metadata:
    name: "frontend"
    namespace: demo
  spec:
    selector:
      matchLabels:
        app: frontend
     ...
  

基本結構

授權政策包含政策範圍、action 和 rules 清單：

• 如上一節所述，政策範圍可以是整個網格、命名空間或特定工作負載。如果加入這項欄位，selector 欄位會指定政策目標。

• 「action」欄位會指定要 ALLOW 或 DENY 要求。如果未指定動作，系統預設會將動作設為 ALLOW。為求清楚，建議您一律指定動作。(授權政策也支援 AUDIT 和 CUSTOM 動作。AUDIT 動作僅支援部分平台。詳情請參閱「支援的功能」一節。

• rules 指定觸發動作的時間。

  • rules 中的 from 欄位會指定要求的來源。

  • rules 中的 to 欄位會指定要求的作業。

  • when 欄位會指定套用規則所需的其他條件。

在下列範例中：

• 這項政策會套用至 demo 命名空間中對 frontend 服務提出的要求。

• 要求標頭中含有「hello:world」時，系統會允許要求；否則會拒絕要求。

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "hello-world"
  namespace: demo
spec:
  selector:
    matchLabels:
      app: frontend
  action: ALLOW
  rules:
  - when:
    - key: request.headers[hello]
      values: ["world"]

要求作業的存取權控管

您可以在 rules 下方新增 to 區段，控管特定要求作業的存取權，例如 HTTP 方法或 TCP 連接埠。在下列範例中，只有 GET 和 POST HTTP 方法允許傳送至 demo 命名空間中的 currencyservice。

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

對已驗證身分進行存取權控管

在先前的範例中，政策允許來自未經驗證工作負載的要求。如果已啟用STRICT相互 TLS (mTLS)，您可以在「source」部分，根據要求來源的工作負載或命名空間身分限制存取權。

• 使用 principals 或 notPrincipal 欄位，控管工作負載層級的存取權。

• 使用 namespaces 或 notNamespaces 欄位，控管命名空間層級的存取權。

如要使用上述所有欄位，必須啟用 STRICT mTLS。如果無法設定 STRICT mTLS，請參閱「拒絕純文字要求」一文，瞭解替代解決方案。

已識別的工作負載

在下列範例中，只有來自 frontend 服務的要求，才能存取 currencyservice。系統會拒絕其他工作負載對 currencyservice 的要求。

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "currencyservice"
  namespace: demo
spec:
  selector:
    matchLabels:
      app: currencyservice
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["example-project-1234.svc.id.goog/ns/demo/sa/frontend-sa"]

如要指定服務帳戶，principals 必須採用下列格式：

principals: ["PROJECT_ID.svc.id.goog/ns/NAMESPACE/sa/SERVICE_ACCOUNT_NAME"]

如果您使用叢內 Cloud Service Mesh 和 Citadel CA，則 cluster.local 是信任網域。在所有其他情況下，PROJECT_ID.svc.id.goog是網格的信任網域。

「信任網域」對應於系統的信任根，是工作負載身分的一部分。Cloud Service Mesh 會使用信任網域，在網格中建立所有身分。舉例來說，在 SPIFFE ID spiffe://mytrustdomain.com/ns/default/sa/myname 中，子字串 mytrustdomain.com 指定工作負載來自名為 mytrustdomain.com 的信任網域。

使用 Cloud Service Mesh 憑證授權單位時，信任網域會由 Cloud Service Mesh 自動產生。這項功能是以叢集的工作負載集區為基礎。

只要叢集共用相同的信任根，多叢集網格中就能有一或多個信任網域。

已識別的命名空間

以下範例顯示的政策會拒絕來源不是 foo 命名空間的要求：

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

值比對

授權政策中的大部分欄位都支援下列所有比對結構定義：

• 完全比對：完全比對字串。
• 使用 "*" 萬用字元進行萬用字元比對：
  • 前置字元比對：以 "*" 結尾的字串。舉例來說，"test.example.*" 符合 "test.example.com" 或 "test.example.com.cn"。
  • 後置字串比對：以 "*" 開頭的字串。舉例來說，"*.example.com" 符合 "eng.example.com" 或 "test.eng.example.com"。
• 存在比對：如要指定欄位必須存在且不得為空，請使用 fieldname: ["*"] 格式。這與將欄位留空不同，後者表示比對任何內容，包括空白。

但有幾種例外情形。舉例來說，下列欄位僅支援完全相符：

• 「when」區段下方的「key」欄位
• 「source」部分下方的「ipBlocks」
• 「to」區段下方的「ports」欄位

以下範例政策允許存取具有 /test/* 前置字元或 */info 後置字元的路徑：

apiVersion: security.istio.io/v1beta1
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，Cloud Service Mesh 支援排除比對。如果要求路徑不是 /healthz，下列範例會要求有效的 principals 要求 (衍生自 JWT 驗證)。因此，這項政策會將 /healthz 路徑的要求排除在 JWT 驗證之外：

apiVersion: security.istio.io/v1beta1
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: ["*"]

拒絕純文字要求

在 Cloud Service Mesh 中，系統預設會啟用自動 mTLS。使用自動雙向傳輸層安全標準時，用戶端補充資訊 Proxy 會自動偵測伺服器是否具有補充資訊。用戶端輔助容器會將 mTLS 傳送至含有輔助容器的工作負載，並將純文字傳送至不含輔助容器的工作負載。為確保最高安全性，建議您啟用嚴格的 mTLS。

如果無法為工作負載或命名空間啟用 STRICT 模式的 mTLS，可以採取下列做法：

• 建立授權政策，明確允許具有非空白 namespaces 或非空白 principals 的流量，或
• 拒絕含有空白 namespaces 或 principals 的流量。

由於 namespaces 和 principals 只能透過 mTLS 要求擷取，因此這些政策會有效拒絕任何純文字流量。

如果要求中的主體為空白 (純文字要求就是這種情況)，下列政策會拒絕要求。如果主體不為空白，這項政策就會允許要求。["*"] 代表非空白的相符項目，而與 notPrincipals 搭配使用則代表空白主體的相符項目。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-mtls
  namespace: NAMESPACE
spec:
  action: DENY
  rules:
  - from:
    - source:
        notPrincipals: ["*"]

授權政策優先順序

您可以分別設定 ALLOW 和 DENY 授權政策，但必須瞭解政策優先順序和預設行為，確保政策能達到預期效果。下圖說明政策優先順序。

以下各節的範例政策說明瞭部分預設行為，以及您可能會覺得有用的情況。

禁止所有項目

以下範例顯示不符合任何內容的 ALLOW 政策。根據預設，如果沒有其他ALLOW政策，系統一律會拒絕要求。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-nothing
spec:
  action: ALLOW

建議您從「禁止一切」政策開始，逐步新增更多 ALLOW 政策，開放更多工作負載的存取權，這是良好的安全做法。

拒絕所有存取要求

以下範例顯示與所有項目相符的 DENY 政策。因為系統會先評估 DENY 政策，再評估 ALLOW 政策，所以即使有符合要求的 ALLOW 政策，所有要求都會遭到拒絕。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-all
spec:
  action: DENY
  rules:
  - {}

如果您想暫時停用所有工作負載存取權，全拒絕政策就非常實用。

允許所有存取權

以下範例顯示的 ALLOW 政策會比對所有項目，並允許完整存取工作負載。允許所有要求的政策一律會允許要求，因此其他政策都無效。ALLOW

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-all
spec:
  action: ALLOW
  rules:
  - {}

如果您想暫時開放工作負載的完整存取權，允許所有政策就很有用。如果存在任何 DENY 政策，要求仍可能遭到拒絕，因為系統會先評估 DENY 政策，再評估 ALLOW 政策。

最佳做法

1. 為各項服務建立 Kubernetes 服務帳戶，並在 Deployment 中指定服務帳戶。例如：

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: frontend-sa
     namespace: demo
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: frontend
     namespace:demo
   spec:
     selector:
       matchLabels:
         app: frontend
     template:
       metadata:
         labels:
           app: frontend
       spec:
         serviceAccountName: frontend-sa
       ...
   

2. 從完全禁止存取政策開始，逐步新增 ALLOW 政策，開放更多工作負載存取權。

3. 如果您的服務使用 JWT：

   1. 建立 DENY 政策，封鎖未經驗證的要求，例如：

      apiVersion: security.istio.io/v1beta1
      kind: AuthorizationPolicy
      metadata:
        name: requireJWT
        namespace: admin
      spec:
        action: DENY
        rules:
        -  from:
          - source:
              notRequestPrincipals: ["*"]
      

   2. 套用禁止一切的政策。

   3. 為每個工作負載定義 ALLOW 政策。如需範例，請參閱「JWT 權杖」。

後續步驟

進一步瞭解 Cloud Service Mesh 安全性功能：

• 設定 Cloud Service Mesh 使用者驗證
• 設定服務的稽核政策
• 設定傳輸安全性
• 整合 Identity-Aware Proxy 與 Cloud Service Mesh
• 在 GKE 叢集中使用 Cloud Service Mesh 輸出閘道的最佳做法

如要進一步瞭解授權政策，請參閱 Istio 說明文件：

• 授權政策範例
• 授權政策疑難排解