雲原生網關支援自訂鑒權服務,方便在網關入口處完成鑒權,避免每個後端服務都接入鑒權服務。本文介紹如何為雲原生網關配置自建認證鑒權。
背景資訊
服務端通常根據用戶端請求攜帶的憑證資訊(即Token)來保護對外暴露的API介面的通訊安全。Token形式沒有嚴格規定,一般根據實際業務情境決定。
如果Token採用的是JSON WEB Token (JWT),那麼在任何時間、任何地點都可以利用公開金鑰來對Token的簽名進行驗簽,無需訪問一個中心化的鑒權服務。
如果Token的形式是業務方自訂的格式,則服務端收到請求後,必須額外訪問中心化的鑒權服務來完成鑒權操作,以此保護API介面的通訊安全。雲原生網關支援自訂鑒權。
下面以一個樣本來說明雲原生網關接入自建的鑒權服務後的請求處理流程。

用戶端向網關發起認證請求,例如登入操作。
網關將認證請求直接轉寄給認證服務。
認證服務讀取請求中的驗證資訊(例如使用者名稱、密碼)進行驗證,驗證通過後返回憑證資訊(Token)給網關,由網關響應給用戶端。
用戶端向網關發起業務請求,例如下單操作/order,請求中攜帶上一步中身份認證成功後頒發的Token。
網關通過截取原始業務請求的Path(包含Query Parameters)、HTTP方法(GET、POST等)和Token來形成一個新的請求報文,向接入的自建鑒權服務發起鑒權請求。您需要在網關控制台配置Token所在的HTTP Header,另外您可以根據需要開啟允許攜帶原始請求的Body。
假設自建鑒權服務的鑒權API是/validateToken,那麼鑒權請求的真實Path是鑒權API加上原始業務請求的Path後的結果,即/validateToken/order。
鑒權服務收到鑒權請求後,既可以根據Token完成校正Token合法性的操作,又可以根據原始業務請求的Path完成鑒權操作。
如果您鑒權服務的鑒權響應可以修改HTTP狀態代碼,那麼您可以利用HTTP狀態代碼來反映鑒權結果。
鑒權服務返回HTTP狀態代碼為200,表明Token合法且Token有許可權訪問該後端資源。網關繼續將原始業務請求轉寄給受保護的後端服務,收到業務響應後再次轉寄給用戶端,完成下單操作。
鑒權服務返回HTTP狀態代碼為401或者403,表明Token不合法或Token無許可權訪問該後端資源。網關直接返回鑒權服務的響應給用戶端,此次下單操作失敗。
如果您的鑒權服務受業務本身限制要求鑒權響應的HTTP狀態代碼統一為200,那麼您可以利用內建的HTTP頭部
x-mse-external-authz-check-result。鑒權服務的回應標頭部
x-mse-external-authz-check-result的結果為true,表明Token合法或Token有許可權訪問該後端資源。網關繼續將原始業務請求轉寄給受保護的後端服務,收到業務響應後再次轉寄給用戶端,完成下單操作。鑒權服務的回應標頭部
x-mse-external-authz-check-result的結果為false,表明Token不合法或Token無許可權訪問該後端資源。網關直接返回鑒權服務的響應給用戶端,此次下單操作失敗。
建立自建認證鑒權
登入MSE網關管理主控台。
在左側導覽列,選擇云原生网关 > 网关列表,並在頂部功能表列選擇地區。
在网关列表頁面,單擊目標網關名稱。
在左側導覽列,選擇安全管理 > 全局认证鉴权。
在全域認證鑒權頁面,單擊建立鑒權,然後在建立鑒權面板,配置網關鑒權相關參數,最後單擊確定。
配置項
說明
鑒權名稱
自訂雲原生網關鑒權的名稱。
鑒權類型
選擇自建的鑒權服務。
鑒權服務
選擇鑒權的後端服務,可以在服務管理中添加。相關內容,請參見添加服務。
說明僅支援選擇HTTP協議的服務,不支援Dubbo等其他協議的服務。
如果具有多個連接埠的K8s Service,則預設取第一個連接埠。如果您希望使用其他連接埠,需要在Container Service中建立一個額外的K8s Service且只使用目標連接埠。
鑒權API
設定鑒權服務提供的鑒權API的Path,API的Path需是首碼匹配。
例如,您的鑒權服務基於SpringMVC構建,對外開放的鑒權API為/check,那麼處理/check/**的請求設定如下:
@RequestMapping("/check/**") public ResponseEntity<RestResult<String>> check(){}Token位置
設定Token在請求報文中的Header位置,常見的有Authorization和Cookie。您可以選擇下拉選擇或手動輸入的方式設定Token位置。
鑒權請求中允許攜帶的頭部
如果需要額外攜帶用戶端請求中的頭部,那麼需要在欄位中按需配置頭部。
說明Host、Method、Path和Content-Length頭部會被預設添加,您無需手動添加。
鑒權響應中允許保留的頭部
如果需要將鑒權響應中的頭部添加到用戶端請求中,那麼需要在欄位中按需配置頭部。
說明如果用戶端請求中已經有該頭部,那麼其值將會被覆蓋。
鑒權請求中允許攜帶Body
勾選鑒權請求中允許攜帶Body後,鑒權請求會包含原始請求的Body。
其中,Body最大位元組數表示允許鑒權請求攜帶Body的最大位元組數。單位:位元組。
逾時時間
設定等待鑒權服務返回結果的最大等待時間。單位:秒,預設逾時時間為10秒。
模式
支援寬鬆模式和strict 模式,建議您使用寬鬆模式。
寬鬆模式:當鑒權服務不可用時(鑒權服務建立串連失敗或者返回5xx請求),網關接受用戶端請求。
strict 模式:當鑒權服務不可用時(鑒權服務建立串連失敗或者返回5xx請求),網關拒絕用戶端請求。
簡單條件授權
在授權右側單擊簡單條件。簡單條件授權模式支援白名單模式和黑名單模式。
白名單模式:白名單中的Hosts和Paths無需校正即可訪問,其餘Hosts和Paths都需要校正。
黑名單模式:黑名單中的Hosts和Paths需要校正,其餘Hosts和Paths可直接存取。
單擊+ 規則條件,佈建要求網域名稱、路徑和要求標頭。
網域名稱:請求訪問的網域名稱,即Hosts。
路徑(Path):請求訪問的介面Path,即Paths。
路徑匹配條件:Path支援精確匹配、首碼匹配和正則匹配。
精確匹配:輸入完整的Path,例如/app/v1/order。
首碼匹配:輸入Path的首碼,並且末尾填一個*。例如,匹配所有以/app開頭的請求,那麼需設定為/app/*。
正則匹配:正則匹配的文法遵循Google Re2規範。詳細資料,請參見Re2文法。
大小寫敏感:若選中此項,路徑匹配值會區分大小寫。
要求標頭(Header):請求訪問的頭部資訊,即Header。單擊+要求標頭配置,可以配置多個Header,各個Header之間是與的關係。
HeaderKey:Header欄位名。
條件:Header支援的匹配條件。
等於:請求Header集合中指定Key的值與輸入值相等。
不等於:請求Header集合中指定Key的值與輸入值不相等。
存在:請求Header集合中存在輸入Key值。
不存在:請求Header集合中不存在輸入Key值。
包含:請求Header集合中指定Key的值包含輸入值。
不包含:請求Header集合中指定Key的值不包含輸入值。
首碼:請求Header集合中指定Key的值以輸入值為首碼。
尾碼:請求Header集合中指定Key的值以輸入值為尾碼。
正則:請求Header集合中指定Key的值匹配輸入的Regex,正則匹配的文法遵循Google Re2規範。詳細資料,請參見Re2文法。
值:Header欄位的取值。
複雜條件授權
在授權右側單擊複雜條件。
複雜條件授權支援通過YAML配置Envoy的permission資料結構來配置基於與/或/非組合條件邏輯的授權規則。當滿足配置的條件時執行鑒權邏輯;不滿足條件的請求無需鑒權即可訪問。
返回全域認證鑒權頁面查看鑒權資訊,如果已包含建立的網關鑒權資訊,說明網關自建認證鑒權建立成功。
查看並管理鑒權服務
登入MSE網關管理主控台。
在左側導覽列,選擇云原生网关 > 网关列表,並在頂部功能表列選擇地區。
在网关列表頁面,單擊目標網關名稱。
在左側導覽列,選擇安全管理 > 全局认证鉴权。
在全域認證鑒權頁面,單擊目標鑒權規則操作列的詳情,可查看當前服務的基本資料和認證配置,也可查看並管理授權資訊。

您可在授權資訊地區,單擊建立授權資訊。在對話方塊中輸入請求網域名稱和請求Path,並選擇匹配方式,然後單擊確定新增授權規則。
相關操作
您還可以執行以下其他動作,管理網關的認證鑒權:
開啟鑒權:在全局认证鉴权頁面,單擊目標鑒權規則操作列的開啟,使認證鑒權資訊生效。
關閉鑒權:在全局认证鉴权頁面,單擊目標鑒權規則操作列的關閉,關閉網關認證鑒權資訊。
編輯鑒權:在全局认证鉴权頁面,單擊目標鑒權規則操作列的編輯,可編輯網關認證鑒權資訊。
刪除鑒權:在全局认证鉴权頁面,單擊目標鑒權規則操作列的刪除,可刪除網關認證鑒權資訊。
只有在認證鑒權資訊關閉的狀態下才可執行刪除操作。
複雜條件授權樣本
正則匹配網域名稱樣本
本樣本中,只對exampleA.com和exampleB.com兩個網域名稱下首碼匹配路徑的請求執行鑒權邏輯。注意此處regex欄位配置的正則需要完全符合,而非部分匹配。
本樣本中,test.exampleA.com將無法命中條件,無需鑒權即可訪問。
permissions:
# and_rules 表示下面的所有 rules 條件同時成立時執行鑒權
- and_rules:
rules:
- url_path:
# 首碼匹配路徑
path:
prefix: /
- header:
# 正則匹配
safe_regex_match:
regex: "(exampleA\\.com|exampleB\\.com)"
# 支援HTTP Pseudo-Header規範,可通過":authority"這個Header來擷取網域名稱
name: ":authority"與/或/非多條件組合樣本
本樣本滿足以下條件:
exampleA.com/api首碼開頭的請求需要鑒權,但是:
exampleA.com/api/appa/bbb不需要鑒權。
exampleA.com/api/appb/ccc不需要鑒權。
exampleB.com下所有請求需要鑒權,但是:
exampleB.com/api/appa/bbb不需要鑒權。
exampleB.com/api/appb/ccc不需要鑒權。
exampleB.com/api/appc首碼開頭的不需要鑒權,但是:
exampleB.com/api/appc/bbb/ccc需要鑒權。
exampleB.com/api/appc/ccc/ddd需要鑒權。
整理邏輯如下圖所示:

對應的YAML配置如下:
permissions:
# or_rules 表示下面的所有 rules 條件中,有任意一個條件成立時執行鑒權
- or_rules:
rules:
# and_rules,表示下面所有 rules 同時滿足,此 rule 條件才成立
# 規則一
- and_rules:
rules:
- url_path:
path:
exact: /api/appc/bbb/ccc
- header:
exact_match: "exampleB.com"
name: ":authority"
# 規則二
- and_rules:
rules:
- url_path:
path:
exact: /api/appc/ccc/ddd
- header:
exact_match: "exampleB.com"
name: ":authority"
- and_rules:
rules:
# 規則三
- url_path:
path:
prefix: /api/
# not_rule 表示下面的配置不滿足時,此 rule 條件才成立
# 規則四
- not_rule:
url_path:
path:
exact: /api/appa/bbb
# 規則五
- not_rule:
url_path:
path:
exact: /api/appb/ccc
- header:
exact_match: "exampleA.com"
name: ":authority"
- and_rules:
rules:
# 規則六
- url_path:
path:
prefix: /
# not_rule 表示下面的配置不滿足時,此 rule 條件才成立
# 規則七
- not_rule:
url_path:
path:
exact: /api/appa/bbb
# 規則八
- not_rule:
url_path:
path:
exact: /api/appb/ccc
# 規則九
- not_rule:
url_path:
path:
prefix: /api/appc/
- header:
exact_match: "exampleB.com"
name: ":authority"