Istio Service Mesh中的受權與鑑權概念詳解

時間 2019-11-17

標籤 istio service mesh 受權概念詳解简体版

原文原文鏈接

上週給你們分享了一篇必讀！Istio Service Mesh中的流量管理概念解析，此次再給你們分享一篇Istio中重要功能和概念——受權（authorization）與鑑權（authentication）的解析。git

將單體應用程序分解爲微服務可提供各類好處，包括更好的靈活性、可伸縮性以及服務複用的能力。可是，微服務也有特殊的安全需求：github

爲了抵禦中間人攻擊，須要流量加密。api
爲了提供靈活的服務訪問控制，須要雙向 TLS 和細粒度的訪問策略。安全
要審覈誰在何時作了什麼，須要審計工具。服務器

Istio Security 嘗試提供全面的安全解決方案來解決全部這些問題。微信

本頁概述瞭如何使用 Istio 的安全功能來保護您的服務，不管您在何處運行它們。特別是 Istio 安全性能夠緩解針對您的數據，端點，通訊和平臺的內部和外部威脅。網絡

Istio 安全概述架構

Istio 安全功能提供強大的身份，強大的策略，透明的 TLS 加密以及用於保護您的服務和數據的身份驗證，受權和審計（AAA）工具。 Istio 安全的目標是：框架

默認安全 : 應用程序代碼和基礎結構無需更改運維
深度防護 : 與現有安全系統集成，提供多層防護
零信任網絡 : 在不受信任的網絡上構建安全解決方案

訪問咱們的Mutual TLS Migration docs，開始在部署的服務中使用Istio安全功能。請訪問咱們的安全任務，有關使用安全功能的詳細說明。

如圖所示，Istio 的 Citadel 用加載 Secret 卷的方式在 Kubernetes 容器中完成證書和密鑰的分發。若是服務運行在虛擬機或物理機上，則會使用運行在本地的 Node agent，它負責在本地生成私鑰和 CSR（證書籤發申請），把 CSR 發送給 Citadel 進行簽署，並把生成的證書和私鑰分發給 Envoy。

頂層架構

Istio 中的安全性涉及多個組件：

Citadel 用於密鑰和證書管理
Sidecar 和周邊代理 實現客戶端和服務器之間的安全通訊
Pilot 將受權策略和安全命名信息分發給代理
Mixer 管理受權和審計

Istio 安全架構

在下面的部分中，咱們將詳細介紹 Istio 安全功能。

Istio 身份

身份是任何安全基礎架構的基本概念。在服務到服務通訊開始時，雙方必須與其身份信息交換憑證以用於相互認證目的。在客戶端，根據安全命名信息檢查服務器的標識，以查看它是不是該服務的受權運行程序。在服務器端，服務器能夠根據受權策略肯定客戶端能夠訪問哪些信息，審覈誰在什麼時間訪問了什麼，根據服務向客戶收費他們使用並拒絕任何未能支付帳單的客戶訪問服務。

在 Istio 身份模型中，Istio 使用一流的服務標識來肯定服務的身份。這爲表示人類用戶，單個服務或一組服務提供了極大的靈活性和粒度。在沒有此類身份的平臺上，Istio 可使用能夠對服務實例進行分組的其餘身份，例如服務名稱。

不一樣平臺上的 Istio 服務標識：

Kubernetes: Kubernetes 服務賬戶
GKE/GCE: 可使用 GCP 服務賬戶
GCP: GCP 服務賬戶
AWS: AWS IAM 用戶/角色賬戶
On-premises (non-Kubernetes): 用戶賬戶，自定義服務賬戶，服務名稱，istio 服務賬戶或 GCP 服務賬戶。

自定義服務賬戶引用現有服務賬戶，就像客戶的身份目錄管理的身份同樣。

Istio 安全與 SPIFFE

SPIFFE 標準提供了一個框架規範，該框架可以跨異構環境引導和向服務發佈身份。

Istio 和 SPIFFE 共享相同的身份文件：SVID (SPIFFE可驗證身份證件）。例如，在 Kubernetes 中，X.509 證書的 URI 字段格式爲」spiffe:///ns//sa/「。這使 Istio 服務可以創建和接受與其餘 SPIFFE 兼容系統的鏈接。

Istio 安全性和 SPIRE，它是 SPIFFE 的實現，在 PKI 實現細節上有所不一樣。 Istio 提供更全面的安全解決方案，包括身份驗證，受權和審計。

PKI

Istio PKI 創建在 Istio Citadel 之上，可爲每一個工做負載安全地提供強大的工做負載標識。 Istio 使用 X.509 證書來攜帶 SPIFFE 格式的身份。 PKI 還能夠大規模自動化密鑰和證書輪換。

Istio 支持在 Kubernetes pod 和本地計算機上運行的服務。目前，咱們爲每一個方案使用不一樣的證書密鑰配置機制。

Kubernetes 方案

Citadel 監視 Kubernetes apiserver，爲每一個現有和新的服務賬戶建立 SPIFFE 證書和密鑰對。Citadel 將證書和密鑰對存儲爲 Kubernetes secret。
建立 pod 時，Kubernetes 會根據其服務賬戶經過 Kubernetes secret volume將證書和密鑰對掛載到 pod。
Citadel 監視每一個證書的生命週期，並經過重寫 Kubernetes 祕密自動輪換證書。
Pilot 生成安全命名信息，該信息定義了哪些 Service Account 能夠運行哪些服務。Pilot 而後將安全命名信息傳遞給sidecar envoy。

本地機器方案

Citadel 建立 gRPC 服務以獲取證書籤名請求（CSR）。
節點代理生成私鑰和 CSR，並將 CSR 及其憑據發送給 Citadel 進行簽名。
Citadel 驗證 CSR 承載的憑證，並簽署 CSR 以生成證書。
節點代理將從 Citadel 接收的證書和私鑰發送給 Envoy。
上述 CSR 過程會按期重複進行證書和密鑰輪換。

代理程序代理節點（開發中）

在不久的未來，Istio 將在 Kubernetes 中使用節點代理進行證書和密鑰提供，以下圖所示。請注意，本地計算機的標識提供流程是相同的，所以咱們僅描述 Kubernetes 方案。

PKI 與 Kubernetes 中的節點代理

流程以下：

Citadel 建立一個 gRPC 服務來接受 CSR 請求。
Envoy 經過 Envoy secret 發現服務（SDS）API 發送證書和密鑰請求。
收到 SDS 請求後，節點代理會建立私鑰和 CSR，並將 CSR 及其憑據發送給 Citadel 進行簽名。
Citadel 驗證 CSR 中攜帶的憑證，並簽署 CSR 以生成證書。
節點代理經過 Envoy SDS API 將從 Citadel 接收的證書和私鑰發送給 Envoy。
上述 CSR 過程會按期重複進行證書和密鑰輪換。

最佳實踐

在本節中，咱們提供了一些部署指南並討論了一個真實的場景。

部署指南

若是有多個服務運維團隊（又名 SRE）在中型或大型集羣中部署不一樣的服務，咱們建議建立一個單獨的 Kubernetes 命名空間（namespace）讓每一個 SRE 團隊隔離本身的訪問權限。例如，您能夠爲 team1 建立 team1-ns 命名空間，爲 team2 建立 team2-ns 命名空間，這樣兩個團隊都沒法訪問彼此的服務。

⚠️若是 Citadel 遭到入侵，則可能會暴露集羣中的全部託管密鑰和證書。咱們強烈建議在專用命名空間中運行 Citadel（例如， istio-citadel-ns），以便僅限管理員訪問羣集。

示例

讓咱們考慮一個帶有三種服務的三層應用程序： photo-frontend， photo-backend 和 datastore。照片 SRE 團隊管理 photo-frontend 和 photo-backend 服務，而數據存儲 SRE 團隊管理 datastore 服務。 photo-frontend服務能夠訪問 photo-backend， photo-backend服務能夠訪問 datastore。可是， photo-frontend服務沒法訪問 datastore。

在這種狀況下，集羣管理員建立三個命名空間： istio-citadel-ns， photo-ns和 datastore-ns。管理員能夠訪問全部命名空間，每一個團隊只能訪問本身的命名空間。照片SRE團隊建立了兩個服務賬戶，分別在 photo-ns命名空間中運行 photo-frontend和 photo-backend。數據存儲區 SRE 團隊建立一個服務賬戶，以在 datastore-ns命名空間中運行 datastore服務。此外，咱們須要在 Istio Mixer 中強制執行服務訪問控制，使得 photo-frontend沒法訪問數據存儲區。

在此設置中，Kubernetes 能夠隔離運維人員管理服務的權限。 Istio 管理全部命名空間中的證書和密鑰，並對服務實施不一樣的訪問控制規則。

認證

Istio 提供兩種類型的身份驗證：

傳輸身份驗證，也稱爲服務間身份驗證：驗證直接客戶端進行鏈接。Istio 提供雙向 TLS 做爲傳輸身份驗證的完整堆棧解決方案。您能夠輕鬆打開此功能，而無需更改服務代碼。這個解決方案：
爲每一個服務提供強大的身份，表示其角色，以實現跨羣集和雲的互操做性。
保護服務到服務通訊和最終用戶到服務通訊。
提供密鑰管理系統，以自動執行密鑰和證書生成、分發和輪換。
來源身份認證，也稱爲最終用戶身份驗證：驗證原始客戶端將請求做爲最終用戶或設備。 Istio 經過 JSON Web Token（JWT）驗證和 Auth0、 FirebaseAuth 、 GoogleAuth 和自定義身份驗證來簡化開發人員體驗，而且輕鬆實現請求級別的身份驗證。

在這兩種狀況下，Istio 都經過自定義 Kubernetes API 將身份認證策略存儲在 Istio配置存儲中。 Pilot 會在適當的時候爲每一個代理以及密鑰更新爲最新狀態。此外，Istio 支持在許可模式下進行身份驗證，以幫助您瞭解策略更改在其生效以前如何影響您的安全狀態。

雙向 TLS 認證

Istio 隧道經過客戶端和服務器端進行服務間通訊 Envoy 代理。對於客戶端調用服務器，遵循的步驟是：

Istio 將出站流量從客戶端從新路由到客戶端的本地 sidecar Envoy。
客戶端 Envoy 與服務器端 Envoy 開始雙向 TLS 握手。在握手期間，客戶端 Envoy 還執行安全命名檢查，以驗證服務器證書中提供的服務賬戶是否有權運行目標服務。
客戶端 Envoy 和服務器端 Envoy 創建了一個雙向的 TLS 鏈接，Istio 將流量從客戶端 Envoy 轉發到服務器端 Envoy。
受權後，服務器端 Envoy 經過本地 TCP 鏈接將流量轉發到服務器服務。

安全命名

安全命名信息包含來自服務器標識的 N 到 N 映射，這些映射在證書中編碼到由發現服務或 DNS 引用的服務名稱。從身份 A 到服務名稱 B 的映射意味着「容許 A 並受權其運行服務 B 」。 Pilot 監視 Kubernetes apiserver，生成安全的命名信息，並將其安全地分發給 sidecar Envoy。如下示例說明了爲何安全命名在身份驗證中相當重要。

假設運行服務 datastore 的合法服務器僅使用 infra-team 標識。惡意用戶擁有 test-team 身份的證書和密鑰。惡意用戶打算模擬服務以檢查從客戶端發送的數據。惡意用戶使用證書和 test-team 身份的密鑰部署僞造服務器。假設惡意用戶成功攻擊了發現服務或 DNS，以將 datastore 服務名稱映射到僞造服務器。

當客戶端調用 datastore 服務時，它從服務器的證書中提取 test-team 標識，並檢查是否容許 test-team 運行帶有安全命名信息的 datastore。客戶端檢測到 test-team 不容許運行 datastore 服務，而且驗證失敗。

認證架構

您可使用身份認證策略爲在 Istio 網格中接收請求的服務指定身份驗證要求。網格操做者使用 .yaml 文件來指定策略。部署後，策略將保存在 Istio 配置存儲中。 Pilot、Istio 控制器監視配置存儲。一有任何的策略變動，Pilot 會將新策略轉換爲適當的配置，告知 Envoy sidecar 代理如何執行所需的身份驗證機制。 Pilot 能夠獲取公鑰並將其附加到 JWT 驗證配置。或者，Pilot 提供 Istio 系統管理的密鑰和證書的路徑，並將它們掛載到應用程序窗格以進行雙向 TLS。您能夠在 PKI 部分中找到更多信息。 Istio 異步發送配置到目標端點。代理收到配置後，新的身份驗證要求會當即生效。

發送請求的客戶端服務負責遵循必要的身份驗證機制。對於源身份驗證（JWT），應用程序負責獲取 JWT 憑據並將其附加到請求。對於雙向 TLS，Istio 提供目標規則。運維人員可使用目標規則來指示客戶端代理使用TLS與服務器端預期的證書進行初始鏈接。您能夠在PKI和身份部分中找到有關雙向 TLS 如何在 Istio 中工做的更多信息。

認證架構

Istio 將兩種類型的身份驗證以及憑證中的其餘聲明（若是適用）輸出到下一層：受權。此外，運維操做者能夠指定將傳輸或原始身份驗證中的哪一個身份做爲 委託人使用。

認證策略

本節中提供了更多 Istio 認證策略方面的細節。正如認證架構中所說的，認證策略是對服務收到的請求生效的。要在雙向 TLS 中指定客戶端認證策略，須要在 DetinationRule 中設置 TLSSettings。TLS 設置參考文檔中有更多這方面的信息。和其餘的 Istio 配置同樣，能夠用 .yaml 文件的形式來編寫認證策略，而後使用 istioctl 進行部署。

下面例子中的認證策略要求 reviews 服務必須使用雙向 TLS：

apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
name: "reviews"
spec:
targets:
- name: reviews
peers:
- mtls: {}

策略存儲範圍

Istio 能夠在命名空間範圍或網絡範圍存儲中存儲身份認證策略：

爲 kind 字段指定了網格範圍策略，其值爲 MeshPolicy，名稱爲 default。例如：

apiVersion: "authentication.istio.io/v1alpha1"
kind: "MeshPolicy"
metadata:
name: "default"
spec:
peers:
- mtls: {}

爲 kind 字段和指定的命名空間指定命名空間範圍策略，其值爲 Policy。若是未指定，則使用默認命名空間。例如，命名空間 ns1：

apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
name: "default"
namespace: "ns1"
spec:
peers:
- mtls: {}

命名空間範圍存儲中的策略只能影響同一命名空間中的服務。 mesh-scope 中的策略能夠影響網格中的全部服務。爲防止衝突和濫用，只能在網狀範圍存儲中定義一個策略。該策略必須命名爲 default而且有一個空的 targets：部分。您能夠在咱們的目標選擇器部分中找到更多信息。

目標選擇器

身份認證策略的目標指定策略適用的服務。如下示例顯示了一個 targets：部分，指定該策略適用於：

任何端口上的 product-page服務。
端口 9000上的評論服務。

targets:
- name: product-page
- name: reviews
ports:
- number: 9000

若是您未提供 targets：部分，則 Istio 將策略與策略存儲範圍內的全部服務匹配。所以， targets：部分能夠幫助您指定策略的範圍：

網格範圍策略：在網格範圍存儲中定義的策略，沒有目標選擇器部分。網格中最多隻能有一個網格範圍的策略。
命名空間範圍的策略：在命名空間範圍存儲中定義的策略，名稱爲 default 且沒有目標選擇器部分。每一個命名空間最多隻能有一個命名空間範圍的策略。
特定於服務的策略：在命名空間範圍存儲中定義的策略，具備非空目標選擇器部分。命名空間能夠具備零個，一個或多個特定於服務的策略。

對於每項服務，Istio 都應用最窄的匹配策略。順序是：特定於服務>命名空間範圍>網格範圍。若是多個特定於服務的策略與服務匹配，則 Istio 隨機選擇其中一個。運營商在配置其策略時必須避免此類衝突。

爲了強制網狀範圍和命名空間範圍的策略的惟一性，Istio 每一個網格只接受一個身份認證策略，每一個命名空間只接受一個身份認證策略。 Istio 還要求網格範圍和命名空間範圍的策略具備特定名稱 default。

傳輸認證

peers：部分定義了策略中傳輸身份驗證支持的身份驗證方法和相關參數。該部分能夠列出多個方法，而且只有一個方法必須知足認證才能經過。可是，從 Istio 0.7 版本開始，當前支持的惟一傳輸身份驗證方法是雙向 TLS。若是您不須要傳輸身份驗證，請徹底跳過此部分。

如下示例顯示了使用雙向 TLS 啓用傳輸身份驗證的 peers：部分。

peers:
- mtls: {}

目前，雙向 TLS 設置不須要任何參數。所以， -mtls：{}， -mtls：或 -mtls：null聲明被視爲相同。未來，雙向 TLS 設置能夠攜帶參數以提供不一樣的雙向 TLS 實現。

來源身份認證

origins: 部分定義了原始身份驗證支持的身份驗證方法和相關參數。 Istio 僅支持 JWT 原始身份驗證。可是，策略能夠列出不一樣發行者的多個 JWT。與傳輸身份驗證相似，只有一種列出的方法必須知足身份驗證才能經過。

如下示例策略爲原始身份驗證指定了一個 origin: 部分，該部分接受 Google 發佈的 JWT：

origins:
- jwt:
issuer: "https://accounts.google.com"
jwksUri: "https://www.googleapis.com/oauth2/v3/certs"

主認證綁定

主認證關係用鍵值對的方式存儲綁定關係。默認狀況下，Istio 使用 peers: 部分中配置的身份驗證。若是在 peers： 部分中未配置身份驗證，則 Istio 將保留身份驗證。策略編寫者可使用 USE_ORIGIN 值覆蓋此行爲。此值將 Istio 配置爲使用 origin 的身份驗證做爲主體身份驗證。未來，咱們將支持條件綁定，例如：當傳輸體爲X時爲 USE_PEER，不然爲 USE_ORIGIN。

如下示例顯示了 principalBinding 鍵，其值爲 USE_ORIGIN：

principalBinding: USE_ORIGIN

更新認證策略

您能夠隨時更改身份認證策略，Istio 幾乎實時地將更改推送到端點。可是，Istio 沒法保證全部端點同時收到新策略。如下是在更新身份認證策略時避免中斷的建議：

啓用或禁用雙向 TLS：使用帶有 mode：鍵和 PERMISSIVE值的臨時策略。這會將接收服務配置爲接受兩種類型的流量：純文本和 TLS。所以，不會丟棄任何請求。一旦全部客戶端切換到預期協議，不管是否有雙向 TLS，您均可以將 PERMISSIVE 策略替換爲最終策略。有關更多信息，請訪問雙向 TLS 的遷移。

peers:
- mtls:
mode: PERMISSIVE

對於 JWT 身份驗證遷移：在更改策略以前，請求應包含新的 JWT。一旦服務器端徹底切換到新策略，舊JWT（若是有的話）能夠被刪除。須要更改客戶端應用程序才能使這些更改生效。

受權和鑑權

Istio 的受權功能 - 也稱爲基於角色的訪問控制（RBAC） - 爲 Istio Mesh 中的服務提供命名空間級別，服務級別和方法級別的訪問控制。它的特色是：

基於角色的語義，簡單易用。
服務到服務和最終用戶對服務的受權。
經過自定義屬性支持的靈活性，例如條件，角色和角色綁定。
高性能，由於 Istio 受權是在 Envoy 本地強制執行的。

受權架構

Istio 受權架構

上圖顯示了基本的 Istio 受權體系結構。運維人員使用 .yaml文件指定 Istio 受權策略。部署後，Istio 將策略保存在 IstioConfigStore中。

Pilot 監督 Istio 受權策略的變動。若是發現任何更改，它將獲取更新的受權策略。 Pilot 將 Istio 受權策略分發給與服務實例位於同一位置的 Envoy 代理。

每一個 Envoy 代理都運行一個受權引擎，該引擎在運行時受權請求。當請求到達代理時，受權引擎根據當前受權策略評估請求上下文，並返回受權結果 ALLOW或 DENY。

啓用受權

您可使用 RbacConfig 對象啓用 Istio Authorization。 RbacConfig對象是一個網格範圍的單例，其固定名稱值爲 default。您只能在網格中使用一個 RbacConfig實例。與其餘 Istio 配置對象同樣， RbacConfig被定義爲Kubernetes CustomResourceDefinition(CRD)對象。

在 RbacConfig對象中，運算符能夠指定 mode值，它能夠是：

OFF：禁用 Istio 受權。
ON：爲網格中的全部服務啓用了 Istio 受權。
ONWITHINCLUSION：僅對 包含字段中指定的服務和命名空間啓用 Istio 受權。
ONWITHEXCLUSION：除了 排除字段中指定的服務和命名空間外，網格中的全部服務都啓用了 Istio 受權。

在如下示例中，爲 default命名空間啓用了 Istio 受權。

apiVersion: "rbac.istio.io/v1alpha1"
kind: RbacConfig
metadata:
name: default
namespace: istio-system
spec:
mode: 'ON_WITH_INCLUSION'
inclusion:
namespaces: ["default"]

受權策略

要配置 Istio 受權策略，請指定 ServiceRole和 ServiceRoleBinding。與其餘 Istio 配置對象同樣，它們被定義爲Kubernetes CustomResourceDefinition (CRD)對象。

ServiceRole定義了一組訪問服務的權限。
ServiceRoleBinding向特定主題授予 ServiceRole，例如用戶，組或服務。

ServiceRole 和 ServiceRoleBinding 的組合規定：容許誰在 哪些條件下 作什麼 。特別：

誰指的是 ServiceRoleBinding 中的 subject 部分。
作什麼指的是 ServiceRole 中的 permissions 部分。
哪些條件指的是你能夠在 ServiceRole 或 ServiceRoleBinding 中使用Istio屬性指定的 conditions 部分。

`ServiceRole`

ServiceRole 規範包括 規則，AKA 權限列表。每條規則都有如下標準字段：

services：服務名稱列表。您能夠將值設置爲 * 以包括指定命名空間中的全部服務。
methods：HTTP 方法名稱列表，對於 gRPC 請求的權限，HTTP 動詞始終是 POST 。您能夠將值設置爲 * 以包含全部 HTTP 方法。
paths：HTTP 路徑或 gRPC 方法。 gRPC 方法必須採用 /packageName.serviceName/methodName的形式，而且區分大小寫。

ServiceRole 規範僅適用於 metadata 部分中指定的命名空間。規則中須要 services 和 methods 字段。 paths 是可選的。若是未指定規則或將其設置爲 *，則它適用於任何實例。

下面的示例顯示了一個簡單的角色： service-admin，它能夠徹底訪問 default 命名空間中的全部服務。

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
name: service-admin
namespace: default
spec:
rules:
- services: ["*"]
methods: ["*"]

這是另外一個角色： products-viewer，它有讀取， GET 和 HEAD，訪問 default 命名空間中的 products.default.svc.cluster.local服務。

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
name: products-viewer
namespace: default
spec:
rules:
- services: ["products.default.svc.cluster.local"]
methods: ["GET", "HEAD"]

此外，咱們支持規則中全部字段的前綴匹配和後綴匹配。例如，您能夠在 default命名空間中定義具備如下權限的 tester 角色：

徹底訪問前綴爲 test-* 的全部服務，例如： test-bookstore， test-performance， test-api.default.svc.cluster.local。
閱讀（ GET）使用 */reviews後綴訪問全部路徑，例如： /books/reviews, /events/booksale/reviews， /reviews in service bookstore.default.svc.cluster.local。

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

在 ServiceRole中， namespace + services + paths + methods的組合定義了如何訪問服務。在某些狀況下，您可能須要爲規則指定其餘條件。例如，規則可能僅適用於服務的某個版本，或僅適用於具備特定標籤的服務，如 foo。您可使用 constraints 輕鬆指定這些條件。

例如，下面的 ServiceRole 定義添加了一個約束， request.headers[version]是 v1或 v2擴展了之前的 products-viewer角色。約束支持的 key值列在約束和屬性頁面中。在屬性是 map的狀況下，例如 request.headers， key是map中的一個條目，例如 request.headers[version]。

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
name: products-viewer-version
namespace: default
spec:
rules:
- services: ["products.default.svc.cluster.local"]
methods: ["GET", "HEAD"]
constraints:
- key: request.headers[version]
values: ["v1", "v2"]

`ServiceRoleBinding`

ServiceRoleBinding 規範包括兩部分：

roleRef指的是同一命名空間中的 ServiceRole 資源。
subjects 分配給角色的列表。

您可使用 user 或一組 properties 顯式指定 subject。 ServiceRoleBinding subject 中的 property 相似於 ServiceRole 規範中的 constraint 。 property 還容許您使用條件指定分配給此角色的一組賬戶。它包含一個 key及其容許的值。約束支持的 key 值列在約束和屬性頁面中。

下面的例子顯示了一個名爲 test-binding-products 的 ServiceRoleBinding，它將兩個主題綁定到名爲 product-viewer 的 ServiceRole 並具備如下 subject