授權政策總覽

與可能在單一位置執行的單體式應用程式不同，全球分散式微服務應用程式會跨網路邊界進行呼叫。這表示應用程式會有更多進入點，也因此更容易遭到惡意攻擊。由於 Kubernetes Pod 具有暫時性 IP，因此傳統的 IP 防火牆規則無法確保工作負載之間的存取權。在微服務架構中，您需要採用新的安全性方法。除了 Kubernetes 服務帳戶和 Istio 安全性政策等安全性功能，Cloud Service Mesh 還提供更多功能，協助您保護應用程式。

本頁面可讓應用程式操作員瞭解 AuthorizationPolicy 自訂資源 (CR) 的總體情況。授權政策可讓您在應用程式 (第 7 層) 和傳輸 (第 3/4 層) 層級啟用工作負載的存取權控管功能。您可以設定授權政策來指定權限，也就是這項服務或使用者可執行的操作。

授權政策

根據預設，系統會允許網格中服務之間 (以及終端使用者與服務之間) 的要求。您可以使用 AuthorizationPolicy CR 為工作負載定義精細的政策。套用授權政策後，Cloud Service Mesh 會將這些政策分發至補充 Proxy。當要求進入工作負載時，附加元件 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 支援排除比對。以下範例需要有效的請求 principals，如果請求路徑不是 /healthz，則會衍生出 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 預設為啟用狀態。透過自動 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 服務帳戶，並在部署中指定服務帳戶。例如：

   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 說明文件：

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