Securing the Gateway: 一個深入探討 Envoy Gateway 高階安全策略與 OIDC 認證實作的技術解析

引言

在現代雲原生架構中,API Gateway 作為服務間通訊的關鍵節點,其安全性與可擴展性直接影響系統整體的穩定性與安全性。Envoy Gateway 作為 Kubernetes Gateway API 的實現方案,不僅簡化了 API Gateway 的部署與管理,更透過其強大的安全策略機制,為網關流量提供端到端的保護。本文將深入探討 Envoy Gateway 的高階安全策略設計,聚焦於 OIDC 認證實作、授權機制與自訂擴展功能,並解析其在實際場景中的應用方式與技術細節。

技術與概念解析

Envoy Gateway 的核心定位

Envoy Gateway 是 Kubernetes Gateway API 的實現,其核心功能在於透過 Gateway API 自動配置 Envoy Proxy,支援 Standalone 或 Kubernetes 環境下的 API 網關部署。與傳統 API Gateway 相比,Envoy Gateway 的優勢在於其與 Kubernetes 生態的深度整合,以及對 Envoy Proxy 的原生支援,使其能夠靈活處理高流量、高可靠性的網關流量。

Security Policy 的雙層級架構

Envoy Gateway 的安全策略(Security Policy)採用兩層級應用設計:

  • 網關層級:定義全域性安全策略,應用於所有路由,例如全域 TLS 配置、通用認證機制。
  • 路由層級:針對特定路由定義獨立策略,可覆蓋網關層級設定,例如針對特定 API 路徑的 OIDC 認證要求。

此設計允許在不同層級進行細粒度控制,同時避免策略衝突,提升管理效率。

認證與授權機制

Envoy Gateway 支援多種認證類型,包括:

  • Basic Auth:基於用戶名與密碼的簡單驗證,適合低安全需求場景。
  • JWT Token:支援自訂聲明(Claim)與簽名驗證,適用於微服務間的服務對服務認證。
  • API Key:從 Header 提取 API Key 並與 Secret 對比,適合 API 消費者身份驗證。
  • OIDC:整合 OpenID Connect 身分提供者(如 Amazon Cognito、自建 Identity Provider),提供標準化的用戶身份驗證與授權。

授權控制則基於用戶身份(Client IP、JWT 聲明、User Agent 等)進行路由訪問控制,並支援多條件組合與自訂授權邏輯,例如:if sub == "user123" && email == "[email protected]"

實作與應用案例

OIDC 認證實作流程

  1. 管理員建立 Security Policy,指定 OIDC 提供者(如 Amazon Cognito)的 Client ID/Secret 與 Issuer URL。
  2. Gateway 自動轉換為 Envoy 配置,應用於 Proxy。
  3. 用戶請求未帶 ID Token 時,Proxy 重定向至 OIDC 登入頁面。
  4. 用戶登入後,取得 Authorisation Code 並交換為 ID Token。
  5. Proxy 驗證 ID Token 後,允許請求至後端服務。

此流程透過標準化的 OIDC 協議,實現用戶身份驗證與授權,並確保 Token 的安全性與有效性。

自建 Identity Provider 配置

在需要自訂身份驗證流程的場景中,可部署自建 Identity Provider(如 Klog)。配置步驟如下:

  1. 建立 Backend 資源,指定 Identity Provider 的 Hostname 與 Port。
  2. 在 Security Policy 中配置 CSR(Client Secret)來自 ConfigMap。
  3. Gateway 使用 CSR 建立 TLS 連線與 Identity Provider 互動。

此方案適用於測試環境、需避免依賴公共 OIDC 提供者,或需自訂驗證流程的場景。

Security Policy 範例配置

以下為一個 OIDC 認證與 JWT 授權的 Security Policy 範例:

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: SecurityPolicy
metadata:
  name: oidc-policy
spec:
  provider:
    type: oidc
    clientID: "your-client-id"
    clientSecretRef:
      name: oidc-secret
    issuerURL: "https://cognito-idp.us-east-1.amazonaws.com/us-east-1_123456789"
  rules:
    - match:
        path:
          prefix: "/myapp"
      action:
        authenticate:
          oidc:
            issuer: "https://cognito-idp.us-east-1.amazonaws.com/us-east-1_123456789"
            clientID: "your-client-id"
            clientSecretRef:
              name: oidc-secret
    - match:
        path:
          prefix: "/secure"
      action:
        authorize:
          jwt:
            issuer: "https://cognito-idp.us-east-1.amazonaws.com/us-east-1_123456789"
            audience: "your-audience"

此配置透過 provider 定義 OIDC 提供者資訊,並透過 rules 指定不同路由的認證與授權策略。

技術優勢與挑戰

關鍵技術點

  • Gateway API 標準化:透過 Kubernetes Gateway API 管理流量路由與安全策略,實現標準化與可擴展性。
  • Policy 附加性:無需修改核心資源,僅需定義附加策略,提升靈活性。
  • 動態擴展:支援自訂認證/授權邏輯,靈活適應不同場景。
  • 透明性:應用層無需處理認證流程,由 Gateway 代理處理,降低開發複雜度。
  • 安全性:支援 TLS、JWT 簽名驗證、IP 位址過濾等機制,確保流量安全。

挑戰與考量

  • 配置複雜度:多層級策略與 OIDC 集成可能增加配置與維護成本。
  • 依賴外部服務:OIDC 認證需依賴外部 Identity Provider,可能影響系統可用性。
  • 性能影響:認證與授權流程可能增加請求處理時間,需進行性能優化。

總結

Envoy Gateway 的高階安全策略與 OIDC 認證實作,為現代雲原生架構提供了強大的安全保障與靈活性。透過網關層級與路由層級的策略設計,結合多種認證與授權機制,能夠有效控制網關流量,確保服務安全。在實際應用中,需根據場景需求選擇適當的認證類型,並仔細配置 Security Policy 以避免策略衝突。同時,自建 Identity Provider 的配置為企業提供了更高的控制權與靈活性,但需權衡其複雜性與維護成本。對於追求高安全性與可擴展性的系統,Envoy Gateway 結合 CNCF 生態的 Gateway API,無疑是值得深入探索的技術方案。