本篇文章大綱

NGINX Ingress Controller 1.10.0 起已正式支援 OpenID Connect （OIDC）身份驗證技術預覽版。 OIDC 是建立在 OAuth 2.0 框架之上的身份層，為現代應用提供了身份驗證和單點登錄（SSO）解決方案。

我們的 OIDC 策略是一種成熟的 SSO 解決方案，能夠支援使用者安全地與多個應用和 Kubernetes 服務進行身份驗證。重要的是，它支援應用使用外部身份供應商（IdP）來驗證使用者身份，卸除了應用處理使用者名或密碼的負擔。

這個新功能是對其他 NGINX Ingress Controller 授權和身份驗證功能（例如 JSON Web Token （JWT）身份驗證）的補充，提供了一個功能強大的單點登錄選項，可配合 NGINX Ingress 資源輕鬆進行配置。

這意味著您可以使用久經實戰考驗的解決方案對用戶進行身份驗證和授權，且開發人員無需在應用中實施這些功能，便可保障應用安全。通過在 Ingress Controller 上實施安全措施和流量控制，您可以在連接的早期階段攔截未經授權和身份驗證的使用者，從而減少 Kubernetes 環境中不必要的資源壓力。

定義 OIDC 策略

通過定義和應用 OIDC 策略，NGINX Plus Ingress Controller 可以作為 OIDC 中繼方運行，能夠啟動並容許經過身份驗證的 Kubernetes 服務會話（服務的入向流量）。我們通過預配置的IdP支援OIDC授權代碼流。

注：OIDC 策略是 NGINX Plus 的專有特性。

以下是一個 OIDC 策略物件配置範例。

apiVersion: k8s.nginx.org/v1alpha1
kind: Policy
metadata:  
name: ingress-oidc-policy
spec:
  oidc:
    clientID: nginx-ingress
    clientSecret: oidc-secret
    authEndpoint: https://idp.example.com/openid-connect/auth
    tokenEndpoint:https://idp.example.com/openidconnect/token
    jwksURI: https://idp.example.com/openid-connect/certs

下面介紹了如何在建立 OIDC 會話時使用策略中的對象

用戶端請求訪問受保護的資源，NGINX Plus Ingress Controller 將其重定向到指定為 authEndpoint 的IdP 進行身份驗證。

如果身份驗證成功，IdP 會發出一個一次性代碼，並將用戶端重定向到一個由 NGINX Plus Ingress Controller 託管的特殊 URI （tokenEndPoint），然後使用一次性代碼交換 JWT，供用戶端在會話期間使用。

NGINX Plus Ingress Controller 儲存 JWT 並向客戶端發送會話 cookie，其中包含對 JWT 的不透明引用。

當用戶端發出後續請求並提供會話 cookie 時，NGINX Plus Ingress Controller 檢索 JWT，並根據存儲在 jwksURI URI 的證書加以驗證。如果 JWT 有效且未過期，NGINX Ingress Controller 會將請求代理到適當的後端 Kubernetes pod。

除了支持預設的 openid 作用域外，NGINX Plus Ingress Controller OIDC 策略還支持標準的 OIDC 作用域。作用域包括使用者身份屬性（例如姓名和電子郵件位址），它們可以用作訪問控制標準。

如果用戶端和 IdP 都允許與 NGINX Plus Ingress Controller 共用這些作用域，那麼它們的對應值在 IdP 的回應中被編碼為 JWT 聲明。

OIDC 策略一旦應用成功，它便可以在其他入向負載均衡配置中得到重複利用，從而簡化向應用和Kubernetes 服務添加身份驗證和授權的過程。

舉例來說，您可以在 VirtualServer 物件中引用 OIDC 策略，並通過將 JWT 聲明作為 HTTP 標頭傳遞給上游應用來修改入向流量。

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: webapp
spec:
  host: webapp.example.com
  tls:
    secret: tls-secret
    redirect:
      enable: true
  upstreams:
  - name: webapp
    service: webapp-svc
    port: 80
  routes:
  - path: /
    policies:
    - name: oidc-policy
    action:
      proxy:
        upstream: webapp
        resquestHeaders:
          pass: true
          set:
          - name: My-Header
            value: ${jwt_claim_profile}

1.10.0 版還有哪些新特性？

NGINX Ingress Controller 1.10.0 的推出延續了我們提供靈活、強大且易於使用的生產級 Ingress Controller 的承諾。 NGINX Ingress Controller 可以配置 Kubernetes Ingress 資源和 NGINX Ingress 資源：

Kubernetes Ingress 資源可最大限度地提高整個 Ingress Controller 實施環境的相容性，並且可使用註釋和自定義範本進行擴展。
NGINX Ingress 資源提供特定的NGINX 配置方案，與通用 Kubernetes Ingress 資源的方式相比更為豐富和安全。

本節中的資訊適用於 NGINX 開源版和 NGINX Plus Ingress Controller。

除了 OIDC 身份驗證，1.10.0 版還提供了以下增強功能和改進功能：

最新的 NGINX Service Mesh 集成
NGINX Service Mesh 0.8.0 版現已可供下載，並能夠與 NGINX Ingress Controller 無縫集成。

行為變更
Policy 物件的 apiVersion 已升級至 v1，且只有某些secret 類型是有效的。

增強的視覺化和紀錄記錄
額外的指標和日誌註釋可簡化故障排除流程，説明您快速發現痛點。

其他新增特性

改進的註釋和 secret 驗證
使用 NGINX App Protect 使用者定義的簽名攔截無法識別的威脅
IP 位址存取控制清單策略升級為生產就緒狀態
Rancher RKE 支援

重要的行為變更

Policy 資源的 apiVersion 已升級至 v1（但相應的模式沒有改變）。如果您使用版本 1.8.0 或 1.9.0 創建了策略，並計劃繼續使用它們，則請在更新後的 apiVersion 版本號下再次創建它們。有關詳細資訊，請參閱版本說明中的升級。

NGINX Ingress Controller 目前只接受某些類型的 secret。請參閱版本說明中的更新secret。

重要的行為變更

・配置佇列指標

監控對於實踐中應用行為的理解和可視化至關重要。監控可以簡化故障排除流程，查明應用中的缺陷和瓶頸，進而説明您快速修復。

在該版本中，我們添加了新的 workqueue 指標，用於報告在任何給定時間下佇列中正在等待的未完成的配置變更數量，以及配置在 NGINX Ingress Controller 佇列中等待被處理的時間。

您可以使用這些指標來確定請求的配置變更是否過多，以及 NGINX Ingress Controller 是否擁有快速處、理配置所需的資源。

如果 Ingress Controller 無法處理大量的配置變更，您可以為當前部署的 NGINX Ingress Controller pod 分配更多的計算資源（CPU 和記憶體），或者增加部署的數量來分散要處理的配置數量。

・日誌註釋（含 Kubernetes 物件名稱）

1.9.0 版為導出到 Prometheus 的 Ingress Controller 指標添加了註釋，以指定 Kubernetes 服務名稱、pod 和 Ingress 資源名稱。

此版本為 NGINX Ingress Controller 日誌添加了相同的註釋。日誌註釋不僅可以提高可視性，而且還可以簡化故障排除流程。

操作人員現在可以將日誌條目與特定的 Kubernetes 服務和資源（例如 Ingress 或 VirtualServer 資源）相關聯，以加快識別需要注意的 Kubernetes 物件。

例如，連接可能會失敗，因為 VirtualServer 資源不包括任何可用於服務連接的上游。

$ kubectl logs NGINX_Ingress_Controller_pod_name -n nginx-ingress
174.115.106.xxx – – [27/Jan/2021:21:36:50 +0000] “GET /tea HTTP/1.1” 503 154 “-” “curl/7.54.0” “-” “app” “virtualserver” “default” “billing-svc”

此外，應用和服務擁有者可以以服務名稱或 Ingress 資源來過濾日誌，以僅訪問屬於其應用的日誌條目。這在早期版本中是不可能實現的，因為其日誌條目未指定服務或 Ingress 資源。

要配置這項日誌功能，請在 NGINX Ingress Controller ConfigMap 的 log-format 字段添加內置變數。

・TCP 指標的註釋

1.10.0 版還在導出到 Prometheus 的 TCP/UDP 指標中添加了關於 Kubernetes 服務名稱、pod 和Ingress 資源名稱的註釋。將 TCP 應用的性能與 Kubernetes 對象相關聯可以簡化故障排除流程。

以下範例是一個關於上游伺服器活動連接的帶註釋的 Prometheus 指標：

#HELP nginx_ingress_nginxplus_stream_upstream_server_active Active connections
#TYPE nginx_ingress_nginxplus_stream_upstream_server_active gauge
nginx_ingress_nginxplus_stream_upstream_server_active{class="nginx",
pod_name="coredns-6b67b8f5d6-pnrwl",resource_name="dns-tcp",resource_namespace="default",resource_type="transportserver",server="10.0.2.20:5353",service="coredns",upstream="ts_default_dns-tcp_dns-app"} 3

其他特性

・驗證 Ingress 註釋

在 Ingress 資源中驗證註釋可防止 NGINX Ingress Controller 因無效註釋值而在重新載入過程中停機，從而提高 NGINX Ingress Controller 的可靠性。相比早期版本，1.10.0 版能夠驗證更多的註釋。

NGINX Ingress Controller 現在還會在應用 Ingress manifest 後，立即報告與 Ingress 資源相關的事件驗證錯誤。使用 kubectl describe 命令可以立即看到錯誤消息，而不必在發生錯誤後查看日誌檔。

$ kubectl describe ing cafe-ingress
...
Events:
Type Reason  Age   From  
Message
  ----     ------          ----  ----         -------
Warning  Rejected  7s   nginx-ingress-controller  default/cafe-ingress was rejected: with error: annotations.nginx.org/
lb-method: Invalid value: "least_cons": Invalid load balancing method: "least_cons"
...

・驗證 Secret

NGINX Ingress Controller 1.10.0 可評估 Kubernetes secret 的內容，並通過防止停機或複雜的故障排除場景來提高可靠性。如果引用的 secret 無效或者不存在，NGINX Ingress Controller 會在與引用 secret 的資源相關的事件中報告該問題。

$ kubectl describe ing cafe
...
Events:
Type     Reason      Age      From                    
Message
  ----     ------     ----  ----         -------
Warning  AddedOrUpdatedWithWarning  8s    nginx-ingress-controller  Configuration for default/cafe-ingress was added or updated; with warning(s): TLS secret cafe-secret is invalid: Failed to validate TLS cert and key: tls: failed to find any PEM data in key input
...

NGINX App Protect 使用者定義的簽名

當企業需要快速阻止威脅但又沒有預先為這些威脅構建簽名時，使用者定義的簽名就會大派用場。

借助 NGINX Ingress Controller 1.10.0，您可以創建 NGINX App Protect 使用者定義的簽名來自定義您的七層安全策略。

在以前的版本中，您只能使用 F5 提供的預定義簽名。在 1.10.0 版中，您可以創建定製簽名，並使用偏移參數和正則表示式來阻止使用者輸入的特定字串串，並指定有關字串位置和格式的複雜規則。

例如，當發現漏洞時，您可以創建定製簽名來規避漏洞，而不是更新整個簽名資料庫。

用戶定義的簽名很容易從其他 F5 WAF 產品移植到 NGINX Ingress Controller，這簡化了所有平台和環境中安全方案的可管理性。

IP 位址存取控制清單策略可投入生產環境

作為 1.10.0 版的一部分，我們正在將 1.8.0 版中引入的 IP 位址存取控制清單（accessControl）策略升級到生產就緒狀態（1.9.0 版中引入的三個策略和本版中引入的 OIDC 策略仍處於預覽模式）。

Rancher Kubernetes Engine 支援

1.10.0 版通過在 Rancher 的目錄中提供 NGINX Ingress Controller，支援在 Rancher Kubernetes Engine （RKE）上運行 NGINX Ingress Controller。

您只需在目錄的使用者介面中點擊幾下，並輸入幾個參數，即可輕鬆安裝 NGINX Ingress Controller。

資源

有關 1.10.0 版的完整變更日誌，請查看版本說明：
https://docs.nginx.com/nginx-ingress-controller/releases/#nginx-ingress-controller-1100

作者：Amir Rawdat
職位：F5技術營銷工程師

查看原文

定義 OIDC 策略

1.10.0 版還有哪些新特性？

重要的行為變更

重要的行為變更

・配置佇列指標

・日誌註釋（含 Kubernetes 物件名稱）

・TCP 指標的註釋

其他特性

・驗證 Ingress 註釋

・驗證 Secret

NGINX App Protect 使用者定義的簽名

IP 位址存取控制清單策略可投入生產環境

Rancher Kubernetes Engine 支援

資源

分享此文章：