認證鑑權對於 API 閘道器的重要性
認證鑑權作為 API 閘道器不可或缺的能力，已然成為使用者在選型 API 閘道器時考量的重要因素之一。
作者錢勇，API7.ai 開發工程師，Apache APISIX Committer
在當下雲原生越發成熟的環境下，API 閘道器最核心的功能可以概括為：連線 API 消費者和 API 提供者。
實際場景中，除去少部分允許匿名訪問的 API 外，提供者往往都會對消費者有所限制，比如只有符合條件的消費者才可以對 API 進行訪問。其次，提供者對於不同的消費者的訪問策略可能並不相同，例如 A、B 消費者都可以訪問 /send_mail API，但每分鐘的呼叫頻次需要區分計算。
從以上兩點可以看出在 API 閘道器層面鑑別和驗證 API 消費者的身份至關重要。本文將介紹雲原生開源 API 閘道器 Apache APISIX 如何實現對於消費者的認證，以及目前被企業廣泛採用的認證方式。進一步介紹 APISIX 的使用者認證體系是如何與其他安全特性聯動使用，從而進一步提升 API 閘道器的安全防護能力。
Apache APISIX 的認證鑑權
Apache APISIX 是一個動態、實時、高效能的 API 閘道器，提供負載均衡、動態上游、灰度釋出、精細化路由、限流限速、服務降級、服務熔斷、身份認證、可觀測性等數百項功能。在認證鑑權方面，APISIX 也是提供了非常多且方便的途徑。
傳統的 HTTP 代理往往只能基於請求域名、客戶端 IP 等粗粒度手段對請求方進行識別，這對於一款 API 閘道器來說是遠遠不夠的，我們需要有更豐富的認證方式來解決越來越複雜的業務需求。而 APISIX 區分於傳統代理的一大優勢就是靈活的外掛擴充套件能力，這其中就包括一套用於使用者認證的外掛集合，這些外掛根據實現方式的不同可以分為兩大類。
第一種是對接外部認證服務，委託其進行認證。
第二種則是在閘道器內部認證，配合 APISIX 設計的 Consumer 物件進行認證。
下面將會依次介紹這兩種認證方式。
對接外部認證服務
在企業採用 API 閘道器之前，系統中往往已經部署了獨立的認證服務，此時我們要如何將 APISIX 與已有的認證服務進行對接呢？APISIX 提供了這樣一系列外掛，它們的工作原理就是通過對接各種外部的認證服務，委託它們完成認證。
例如，我們可以使用 openid-connect 外掛對接任意支援 OIDC 協議的認證服務，下面是一段對接到 Keycloak 服務的樣例配置：
curl http://127.0.0.1:9180/apisix/admin/routes -H "X-Api-Key: your-API-key" -XPOST -d '
{
"uri":"/*",
"plugins":{
"openid-connect":{
"client_id":"apisix", // keycloak 建立 client 時生成
"client_secret":"d5c42c50-3e71-4bbe-aa9e-31083ab29da4",
"discovery":"http://keycloak:8080/auth/realms/apisix_test_realm/.well-known/openid-configuration", // keycloak OpenID Endpoint
"scope":"openid profile",
"bearer_only":false,
"realm":"apisix_test_realm",
"introspection_endpoint_auth_method":"client_secret_post",
"redirect_uri":"http://127.0.0.1:9080/"
}
},
"upstream":{
...
}
}'
閘道器內部認證
Consumer
當來自多渠道的請求到達 API 閘道器後，閘道器需要識別出這些呼叫方。為此，Apache APISIX 提出了 Consumer 概念，用來代表某類服務的呼叫方。
Consumer 物件需要配置認證外掛進行使用，以最簡單的 key-auth 外掛為例：
curl http://127.0.0.1:9180/apisix/admin/consumers -H 'X-API-KEY: your-API-key' -X PUT -i -d '
{
"username": "jack",
"plugins": {
"key-auth": {
"key": "auth-jack"
}
}'
以上配置表示當請求中攜帶指定的 key（auth-jack）時，當前請求將會與 jack 這個消費者進行關聯。可以看到，Consumer 上配置的認證外掛實際上就是一個指定認證機制下的身份憑證，在 key-auth 外掛中，key 即是標識某個消費者的憑證，類似的還有 basic-auth 外掛的使用者名稱與密碼等等。
為路由配置認證外掛
當我們通過 Consumer 將憑證資訊與具體的消費者進行關聯後，還需要在相應的路由上開啟認證外掛：
curl http://127.0.0.1:9180/apisix/admin/routes/orders -H 'X-API-KEY: your-API-key' -X PUT -i -d '
{
"uri": "/orders",
"plugins": {
"key-auth": {
"header": "Authorization"
}
}
}'
以上配置表示在 /orders 這個路由上開啟 key-auth 外掛，驗證效果如下：
curl http://127.0.0.1:9080/orders -H 'Authorization: auth-jack' -i
HTTP/1.1 200 OK
...
curl http://127.0.0.1:9080/orders -H 'Authorization: wrong-key' -i
HTTP/1.1 401 Unauthorized
...
{"message":"Invalid API key in request"}
當來自使用者的請求命中這條路由時，APISIX 會嘗試通過 Authorization 頭部拿到使用者提供的 Key。如果無法獲取或者獲取到的 Key 是不合法的，那麼該請求將會被閘道器直接拒絕，從而保護上游服務。
可以看到以上兩種認證方式中，認證外掛都處於整個體系中的核心地位，它的豐富度將直接影響著 API 閘道器使用者對於認證方式的選擇空間。
APISIX 支援的認證方式
認證鑑權作為計算機世界從第一天起就存在的基礎機制，經過這麼多年的迭代，已經發展成為一個非常多樣化的領域。而 APISIX 的外掛機制極大地降低了實現各種認證方式的開發成本，以下是部分 APISIX 已經支援的主流認證方式。
Key Auth
Key Auth 是目前 APISIX 所支援的認證方式中，使用起來最簡單的。但 key-auth 外掛在實際環境中有著非常豐富的應用場景，例如：收費軟體中的 License、開放 API 平臺中的用於標識開發者的 token 等等，都可以非常輕鬆地使用 key-auth 來實現。並且基於 APISIX 全動態的配置下發能力，Key 可以被迅速建立、吊銷，而且實時生效。
Basic Auth
Basic Auth 是基於使用者名稱、密碼進行認證的方式，常用於網頁登入場景，例如：網站的管理後臺需要管理員登入後才可以使用，那麼我們可以使用 Basic Auth 方式進行認證。
LDAP
LDAP（Lightweight Directory Access Protocol）是一種基於X.500 標準的輕量級檔案訪問協議，通過IP 協議提供訪問控制和維護分散式資訊的目錄資訊，藉助於 LDAP ，運維人員可以細粒度地控制使用者對資源的訪問許可權。通過 APISIX 的 ldap-auth 外掛，可以輕鬆對接實現了 LDAP 協議的平臺，例如微軟的 Active Direcory，或者 Linux 平臺的 OpenLDAP Server，從而能夠精細化地控制 Consumer 對具體路由的訪問許可權。
OIDC
OpenID 是一個去中心化的網上身份認證系統。對於支援 OpenID 的網站，使用者不需要記住像使用者名稱和密碼這樣的傳統驗證標記。取而代之的是，他們只需要預先在一個作為 OpenID 身份提供者（identity provider, IdP）的網站上註冊賬號，而後就可以用這個賬號登入所有對接了該提供者的應用，例如：可以通過知名的 Google 或者 Facebook 服務的賬號來認證我們自身系統的使用者。
針對 OIDC，APISIX 提供了 openid-connect 外掛，可以用於對接支援了 OIDC 協議的認證服務。
Forward Auth
當 APISIX 的標準認證外掛無法滿足你當前需求時，或者當前系統中已經部署了專門的並且是非標準協議的認證服務，此時你可以考慮使用 forward-auth 外掛。使用該外掛可以將使用者的請求通過 HTTP 形式轉發至認證服務中，並在認證服務響應非正常狀態（錯誤碼非 20x）時，返回自定義報錯或者將使用者重定向至認證頁面。
藉助 forward-auth 外掛的能力，可以非常巧妙地將認證與授權邏輯轉移到專門的、非標準協議的外部服務中。
“認證+任意功能”，APISIX 助力 API 安全
使用者認證只是 APISIX 保障 API 安全的第一步，將認證能力與其他安全型別外掛的有機結合將會進一步放大閘道器的安全能力。
ACL 訪問控制
在一個複雜的後端系統中，可能會存在部分 API 的安全限制是高於其他 API 的，這種限制不僅需要攔截匿名使用者，而且需要對認證使用者進行限制，例如：只允許白名單使用者訪問使用者管理 API。
此時我們可以使用 APISIX 提供的 consumer-restriction 外掛去實現一個訪問控制機制。
curl http://127.0.0.1:9180/apisix/admin/routes -H 'X-API-KEY: your-API-key' -X POST -i -d '
{
"uri": "/api/v1/users/admin",
"plugins": {
"key-auth": {},
"consumer-restriction": {
"whitelist": [
"Rose",
"Peter
]
}
},
"upstream": {
...
},
}'
上述配置中，通過 key-auth 和 consumer-restriction 兩個外掛限制了：/api/v1/users/admin 路由需要通過 key auth 認證，並且僅 Rose 和 Peter 可以訪問。
限流限速
前面我們介紹了可以通過在 Consumer 中配置認證外掛將使用者憑證與消費者進行關聯，事實 APISIX Consumer 物件不僅僅可以掛載認證型別的外掛，而是可以像路由和 Service 一樣，掛載任意外掛。
以限流場景舉例，在實際應用中，限流策略往往不是一成不變而是"千人千面"，不同服務等級的呼叫方擁有不同的 API 限流策略是非常常見的需求，這樣的需求是無法通過在路由上掛載限流外掛進行解決的。為此，我們可以在消費者上掛載限流外掛，並且為每一個消費者指定不同的限流策略。
curl http://127.0.0.1:9180/apisix/admin/consumers -H 'X-API-KEY: your-API-key' -X PUT -i -d '
{
"username": "jack",
"plugins": {
"key-auth": {
"key": "jack"
},
"limit-count": {
"count": 200,
"time_window": 60,
"rejected_code": 503,
"key": "$consumer_name",
}
}'
curl http://127.0.0.1:9180/apisix/admin/consumers -H 'X-API-KEY: your-API-key' -X PUT -i -d '
{
"username": "rose",
"plugins": {
"key-auth": {
"key": "rose"
},
"limit-count": {
"count": 1000,
"time_window": 60,
"rejected_code": 503,
"key": "$consumer_name",
}
}'
通過上方的配置，我們為 jack 和 rose 分別指定了不同的限流策略。Rose 在 60 秒內擁有更多的請求次數配額 1000，而 Jack 只有 200 配額。
總結
認證鑑權作為 API 閘道器不可或缺的能力，已然成為使用者在選型 API 閘道器時考量的重要因素之一。
本文中介紹的開源閘道器 Apache APISIX，覆蓋了所有主流的認證方式，可以滿足企業使用者對於認證鑑權的需求。同時 APISIX 還擁有其他以下優勢：
- 豐富的、開箱即用的認證外掛；
- 同時支援內建、外接認證方式，使用者可以自由選擇；
- 支援二次開發，方便對接自定義鑑權中心。
這些優勢都可以幫助企業更輕鬆的落地閘道器層面的認證鑑權，加強 API 安全。
- RESTful API 為何成為頂流 API 架構風格？
- APISIX Ingress 如何使用 Cert Manager 管理證書
- API 閘道器策略的二三事
- 服務網格領域的百花齊放，是否存在一個更優解？
- 馬蜂窩如何利用 APISIX 閘道器實現微服務架構升級
- 為什麼 APISIX Ingress 是比 Ingress NGINX 更好的選擇？
- 基於 APISIX 的服務網格方案 Amesh 積極開發中！
- 盤點微服務架構下的諸多身份驗證方式
- 2022 Apache APISIX 年度記憶
- APISIX Ingress 對 Gateway API 的支援和應用
- 為什麼 APISIX Ingress 是比 Traefik 更好的選擇？
- 當 Amazon Lambda 遇上 Apache APISIX 可以擦出什麼火花？
- 認證鑑權對於 API 閘道器的重要性
- 馬斯克都不懂的 GraphQL，API 閘道器又能對其如何理解？
- APISIX Ingress 如何支援自定義外掛
- Apache APISIX 玩轉 Tongsuo 國密外掛
- 如何基於 APISIX 迭代數字智聯平臺
- 譯文 | A poor man's API
- APISIX 在君潤人力雲原生平臺的架構實踐