使用 Istio 授權進行微分割

描述 Istio 的授權功能，以及如何在各種使用案例中使用它。

2018 年 7 月 20 日 | 作者：Limin Wang

微分割是一種安全技術，可在雲端部署中建立安全區域，並允許組織將工作負載彼此隔離並單獨保護它們。Istio 的授權功能，也稱為 Istio 基於角色的存取控制，為 Istio 網格中的服務提供微分割。它具有以下特點：

在這篇部落格文章中，您將了解主要的授權功能，以及如何在不同情況下使用它們。

特性

RPC 級別的授權

授權是在個別 RPC 的級別上執行的。具體而言，它控制「誰可以存取我的 bookstore 服務」，或「誰可以存取我的 bookstore 服務中的 getBook 方法」。它並非設計用於控制對應用程式特定資源實例的存取，例如存取「儲存貯體 X」或存取「第二層架子上的第三本書」。如今，這種應用程式特定的存取控制邏輯需要由應用程式本身處理。

具有條件的基於角色的存取控制

授權是一個基於角色的存取控制 (RBAC) 系統，與基於屬性的存取控制 (ABAC) 系統形成對比。與 ABAC 相比，RBAC 具有以下優勢：

另一方面，Istio 的授權系統不是傳統的 RBAC 系統。它也允許用戶使用屬性組合來定義條件。這使 Istio 具有表達複雜存取控制策略的彈性。事實上，Istio 授權採用的「RBAC + 條件」模型，具有 RBAC 系統的所有優點，並支持通常 ABAC 系統提供的靈活性。您將在下面的範例中看到一些例子。

高效能

由於其簡單的語義，Istio 授權在 Envoy 上作為原生授權支持強制執行。在執行時間，授權決策完全在 Envoy 過濾器內部本地完成，而無需依賴任何外部模組。這使 Istio 授權能夠實現高效能和高可用性。

使用/不使用主要身分

與任何其他 RBAC 系統一樣，Istio 授權是身分感知的。在 Istio 授權政策中，有一個稱為 user 的主要身分，它表示用戶端的委託人。

除了主要身分外，您還可以指定定義身分的任何條件。例如，您可以將用戶端身分指定為「使用者 Alice 從 Bookstore 前端服務呼叫」，在這種情況下，您具有呼叫服務 (Bookstore frontend) 和終端用戶 (Alice) 的組合身分。

為了提高安全性，您應該啟用身份驗證功能，並在授權政策中使用經過身份驗證的身分。但是，使用授權不需要強身份驗證的身分。Istio 授權可以使用或不使用身分。如果您使用的是舊系統，您可能沒有為您的網格設定相互 TLS 或 JWT 身份驗證。在這種情況下，識別用戶端的唯一方法是，例如，透過 IP。您仍然可以使用 Istio 授權來控制允許哪些 IP 位址或 IP 範圍存取您的服務。

範例

授權任務向您展示如何使用 Istio 的授權功能，來使用Bookinfo 應用程式控制命名空間級別和服務級別的存取。在本節中，您將看到更多關於如何使用 Istio 授權實現微分割的範例。

透過 RBAC + 條件進行命名空間級別分割

假設您在 frontend 和 backend 命名空間中都有服務。您希望允許 frontend 命名空間中的所有服務存取 backend 命名空間中標記為 external 的所有服務。

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: external-api-caller
  namespace: backend
spec:
  rules:
  - services: ["*"]
    methods: ["*”]
    constraints:
    - key: "destination.labels[visibility]”
      values: ["external"]
---
apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: external-api-caller
  namespace: backend
spec:
  subjects:
  - properties:
      source.namespace: "frontend”
  roleRef:
    kind: ServiceRole
    name: "external-api-caller"

上面的 ServiceRole 和 ServiceRoleBinding 表達了「誰被允許在哪些條件下做什麼」（RBAC + 條件）。具體而言：

具有/不具有主要身分的服務/方法級別隔離

這是另一個範例，展示了在服務/方法級別更精細的存取控制。第一步是定義一個 book-reader 服務角色，該角色允許對 bookstore 服務中的 /books/* 資源進行 READ 存取。

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: book-reader
  namespace: default
spec:
  rules:
  - services: ["bookstore.default.svc.cluster.local"]
    paths: ["/books/*”]
    methods: ["GET”]

使用經過身份驗證的用戶端身分

假設您想將此 book-reader 角色授予您的 bookstore-frontend 服務。如果您已為您的網格啟用相互 TLS 身份驗證，您可以使用服務帳戶來識別您的 bookstore-frontend 服務。將 book-reader 角色授予 bookstore-frontend 服務可以透過建立如下所示的 ServiceRoleBinding 來完成：

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: book-reader
  namespace: default
spec:
  subjects:
  - user: "cluster.local/ns/default/sa/bookstore-frontend”
  roleRef:
    kind: ServiceRole
    name: "book-reader"

您可能希望透過添加條件來進一步限制它，即「只有屬於 qualified-reviewer 群組的用戶才允許閱讀書籍」。qualified-reviewer 群組是透過JWT 身份驗證進行身份驗證的終端用戶身分。在這種情況下，用戶端服務身分 (bookstore-frontend) 和終端用戶身分 (qualified-reviewer) 的組合將用於授權政策中。

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: book-reader
  namespace: default
spec:
  subjects:
  - user: "cluster.local/ns/default/sa/bookstore-frontend"
    properties:
      request.auth.claims[group]: "qualified-reviewer"
  roleRef:
    kind: ServiceRole
    name: "book-reader"

用戶端沒有身分

強烈建議在授權政策中使用經過身份驗證的身分以確保安全。但是，如果您有不支援身份驗證的舊系統，您的服務可能沒有經過身份驗證的身分。即使沒有經過身份驗證的身分，您仍然可以使用 Istio 授權來保護您的服務。以下範例顯示您可以在授權政策中指定允許的來源 IP 範圍。

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: book-reader
  namespace: default
spec:
  subjects:
  - properties:
      source.ip: 10.20.0.0/9
  roleRef:
    kind: ServiceRole
    name: "book-reader"

總結

Istio 的授權功能在命名空間級別、服務級別和方法級別提供了授權。它採用「RBAC + 條件」模型，這使其易於使用和理解，如同 RBAC 系統，同時提供 ABAC 系統通常提供的靈活性。Istio 授權由於是在 Envoy 上原生強制執行的，因此實現了高效能。雖然它透過與Istio 身份驗證功能協同工作來提供最佳安全性，但 Istio 授權也可用於為沒有身份驗證的舊系統提供存取控制。

分享這篇文章