使用 F5/NGINX 保護和擴展混合應用（第 3 部分）

在本文中，我們將探討可在外部負載平衡服務上設定的其他零信任的使用案例，包括： 授權和存取、加密mTLS、監控/審計

本文系列 使用 F5 NGINX 保護和擴充混合應用
第一篇：https://www.f5points.com.tw/uu2y
第二篇：https://www.f5points.com.tw/daf0

在本系列文章的第二篇中，我們示範如何在混合環境中使用NGINX Plus 配置基於身份驗證的零信任用例，並部署了NGINX Plus 作為外部負載平衡器，用於連接到Kubernetes 應用的用戶進行路由和身份驗證。  

Screenshot 2024 06 18 At 2.28.21 Pm

在本文中，我們將探討可在外部負載平衡服務上設定的其他零信任使用案例，包括：  

  • 授權和存取
  • 加密mTLS
  • 監控/審計

零信任使用案例1：

授權許多人認為身分驗證和授權可以互換使用，但其實二者並非一回事。 「身份驗證」指根據所提供的憑證驗證使用者身分的流程。

即使經過身份驗證的使用者通過了系統驗證，他們也不一定有權存取受保護的應用程式。這就牽涉到了授權。授權是指在驗證身分權限後授予應用程式存取權限的流程。  

OIDC 驗證中的授權需要從使用者ID 令牌中檢索聲明，並設定條件來驗證使用者是否有權進入系統。  透過JWT 聲明，驗證供應商(IdP) 會向經過驗證的使用者授予一個ID 令牌，其中包含特定的使用者資訊。這些聲明的配置通常由IdP 設定。回顧上一節中配置的OIDC 驗證用例，我們可以從NGINX 鍵值儲存中檢索經過驗證的使用者的ID 令牌。    

$ curl -i http://localhost:8010/api/9/http/keyvals/oidc_acess_tokens

然後，我們可使用jwt.io查看ID 令牌的解碼值。以下是ID 令牌有效載荷資料的解碼範例。  

{
"exp": 1716219261, 
"iat": 1716219201, 
"admin": true, 
"name": "Micash", 
"zone_info": "America/Los_Angeles" 
"jti": "9f8ff4bd-4857-4e12-9634-e5876f786f98", 
"iss": "http://idp.f5lab.com:8080/auth/realms/master", 
"aud": "account", "typ": "Bearer",
"azp": "appworld2024", 
"nonce": "gMNK3tu06j6tp5-jGa3aRhkj4F0P-Z3e04UfcFeqbes"
}

NGINX Plus 可以存取這些作為內建變數的聲明，後者可透過將$jwt_claim_ 前綴新增至所需欄位（例如admin聲明的$jwt_claim_admin）來存取。我們可以輕鬆地對這些聲明設定條件，以便及時攔截未經授權的用戶，防止其進入後端應用。 

再來看看本系列文章上一篇的frontend.conf檔。我們可以根據admin JWT 宣告的值將$jwt_flag變數設為0 或1，然後使用jwt_claim_require指令來驗證ID 令牌。如果ID 令牌的admin聲明設定為false，則會被拒絕。  

map $jwt_claim_admin $jwt_status { 
    "true" 1;
    default 0; 
} 
server { 
    include conf.d/openid_connect.server_conf; # 授权代码流和中继方处理
    error_log /var/log/nginx/error.log debug; # 按需降低严重性级别  
    listen [::]:443 ssl ipv6only=on;
    listen 443 ssl;  
    server_name example.work.gd; 
    ssl_certificate /etc/ssl/nginx/default.crt; # 自签名证书，仅作为示例
    ssl_certificate_key /etc/ssl/nginx/default.key;

    location / { 
       # 本站点受 OpenID Connect 保护
       auth_jwt "" token=$session_jwt;
       error_page 401 = @do_oidc_flow;
       auth_jwt_key_request /_jwks_uri; # 使用 URL 时启用
       auth_jwt_require $jwt_status;
       proxy_pass https://cluster1-https; # 使用 URL 时启用
    }
}

註：NGINX Plus 的授權不僅限於JWT token。從技術上講，您可以對各種屬性設定條件，例如：

  • 會話cookie
  • HTTP 請求頭
  • 來源/目標IP 位址

零信任使用案例2：雙向TLS 認證(mTLS)

就零信任而言，mTLS 是屬於零信任範疇的主流用例之一。舉例來說，企業廣泛使用service mesh（服務網格）技術以符合零信任標準。這是因為service mesh 技術旨在透過使用mTLS 來保護service 到service 通訊。   

從許多方面來說，mTLS 類似於我們在上一節中實現的OIDC 用例。我們只在此處利用數位憑證對流量進行加密和身份驗證。這個底層框架由PKI（公鑰基礎設施）定義。 

以下舉一個簡單的例子來深入淺出地介紹一下此框架，例如您隨身攜帶的駕照。就像駕照可用於驗證持有人的身分一樣，數位憑證能夠用來驗證應用程式的身份。只有國家相關部門才能核發有效的駕照，同樣，只有憑證授權單位(CA) 才可向應用核發有效證明書。同時，確保這些機構的真實性也很重要。因此，每個CA 都必須使用專用安全金鑰來簽發有效憑證。 

使用NGINX 設定mTLS 可分為以下兩部分：  

  • 入向mTLS；確保SSL 用戶端流量安全，並依據受信任CA 驗證用戶端憑證。
  • 出向mTLS；確保SSL 上游流量安全，並將TLS 材料的身份驗證卸載到受信任的HTTPS 後端伺服器。

入向mTLS

只要在server 上下文中新增ssl_client_certificate指令，引用受信任的憑證授權機構，即可在NLK 部署中設定入向mTLS。這將配置NGINX 透過引用的CA 驗證客戶端憑證。

注意：如果沒有引用的CA，則可使用OpenSSL 或Cloudflare PKI 和TLS 工具套件建立一個。

server {
   listen 443 ssl;
   status_zone https://cafe.example.com;
   server_name cafe.example.com;
   ssl_certificate /etc/ssl/nginx/default.crt;
   ssl_certificate_key /etc/ssl/nginx/default.key;
   ssl_client_certificate /etc/ssl/ca.crt;
}

出向mTLS

出向mTLS 與入向mTLS 類似，其中NGINX 會驗證上游應用的證書，而不是來自客戶端的證書。只需將proxy_ssl_trusted_certificate指令新增至server 上下文，即可啟用此功能。您既可引用我們在配置入向mTLS 時用於驗證的相同受信任CA，也可以引用不同的CA。  

除了驗證伺服器憑證以外，作為反向代理的NGINX 還能傳遞憑證/金鑰，並將驗證卸載到HTTPS 上游應用程式。具體方法是，在server 上下文中加入proxy_ssl_certificate和proxy_ssl_certificate_key指令。  

server {
   listen 443 ssl;
   status_zone https://cafe.example.com;
   server_name cafe.example.com;
   ssl_certificate /etc/ssl/nginx/default.crt;
   ssl_certificate_key /etc/ssl/nginx/default.key;

   #入向 mTLS
   ssl_client_certificate /etc/ssl/ca.crt;

   #出向 mTLS
   proxy_ssl_certificate /etc/nginx/secrets/default-egress.crt;
   proxy_ssl_certificate_key /etc/nginx/secrets/default-egress.key;
   proxy_ssl_trusted_certificate /etc/nginx/secrets/default-egress-ca.crt;
}

零信任使用案例3：安全防護聲明標記語言(SAML)

SAML（安全防護聲明標記語言）是替代OIDC 的SSO 解決方案。許多企業可能需要在SAML 和OIDC 之間做出選擇，具體取決於其需求及在目前生產環境中運作的IdP。 SAML 要求SP（服務提供者）透過綁定到SAML IdP 的HTTP POST 來交換XML 訊息。若SP 和IdP 之間交換訊息成功，使用者可使用一套使用者憑證對受保護的後端應用程式進行會話存取。   

在本節中，我們將把NGINX Plus 配置為SP，並透過IdP 啟用SAML。這就像我們將NGINX Plus 配置為OIDC 授權程式碼流中的中繼方一樣（請參閱零信任用例1）。   

設定IdP

一個前提條件是設定IdP。在範例中，我們將在Azure 上設定Microsoft Entra ID。您可以使用所選的SAML IdP。在IdP 中建立SAML 應用程式後，您便可存取所需的SSO 欄位以將SP (NGINX Plus) 連結到IdP (Microsoft Entra ID) 。

Screenshot 2024 06 03 At 1.35.09 Pm

如上圖所示，您將需要點擊Basic SAML Configuration（基本SAML 配置）中Edit（編輯） 旁的鉛筆圖示來編輯基本SAML 配置。填入以下值，然後點選Save（儲存） ：

  •  Identifier (Entity ID)（識別碼（實體ID）） — https://fourth.run.place
  • Reply URL (Assertion Consumer Service URL)（回覆URL（斷言消費者服務URL）） — https://fourth.run.place/saml/acs
  • Sign on URL（登入URL）: https://fourth.run.place
  • Logout URL (Optional)（註銷URL（可選））: https://fourth.run.place/saml/sls

最後，從Microsoft Entra ID 下載Certificate (Raw)（憑證（原始格式）），並將其儲存到NGINX Plus 實例中。此憑證用於驗證從IdP 收到的已簽署SAML 斷言。在將憑證儲存到NGINX Plus 實例後，從下載的憑證中提取公鑰並將其轉換為SPKI 格式。此證書將在下一節配置NGINX Plus 時用到。

$ openssl x509 -in demo-nginx.der -outform DER -out demo-nginx.der
$ openssl x509 -inform DER -in demo-nginx.der -pubkey -noout > demo-nginx.spki

將NGINX Plus 配置為SAML 服務供應商

IdP 設定完成後，我們便可將NGINX Plus 設定為SP，以便與IdP 交換XML 訊息並進行驗證。登入NGINX Plus 實例後，只需複製nginx SAML GitHub 倉庫即可。

$ git clone https://github.com/nginxinc/nginx-saml.git && cd nginx-saml

將設定檔複製到/etc/nginx/conf.d目錄中。

$ cp frontend.conf saml_sp.js saml_sp.server_conf saml_sp_configuration.conf /etc/nginx/conf.d/

請注意，預設情況下，frontend.conf 會以明文http 方式監聽8010 連接埠。您可將kube_lb.conf 合併到frontend.conf中，以啟用TLS 卸載，並將upstream 上下文更新為您想要使用SAML 保護的應用程式端點。

最後，我們需要編輯saml_sp_configuration.conf文件，並根據SP 和IdP 的參數更新map 上下文中的變數：  

  • $saml_sp_entity_id; https://fourth.run.place
  • $saml_sp_acs_url; https://fourth.run.place/saml/acs
  • $saml_sp_sign_authn; false
  • $saml_sp_want_signed_response; false
  • $saml_sp_want_signed_assertion; true
  • $saml_sp_want_encrypted_assertion; false
  • $saml_idp_entity_id;向SP 識別IdP 的唯一識別碼。此欄位可從IdP 檢索出來
  • $saml_idp_sso_url;這是登入URL，也可從IdP 檢索出來
  • $saml_idp_verification_certificate;變量，引用設定IdP 時從上一節下載的憑證。該憑證將驗證從IdP 收到的已簽署斷言。使用完整目錄(/etc/nginx/conf.d/demo-nginx.spki)
  • $saml_sp_slo_url; https://fourth.run.place/saml/sls
  • $saml_idp_slo_url;這是從IdP 檢索出來的註銷URL
  • $saml_sp_want_signed_slo; true

除非有特定的啟用要求，否則在saml_sp_configuration.conf中定義的其餘變數均可保持不變。正確設定變數後，即可重新載入NGINX Plus。  

$ nginx -s reload

測試

現在，我們將驗證SAML 流。開啟瀏覽器，然後在網址列輸入https://fourth.run.place。此操作會將我重新導向到IdP 登入頁面。

Screenshot 2024 06 04 At 11.10.29 Am

在使用憑證登入後，我將可以存取受保護的應用程式

Screenshot 2024 06 04 At 11.12.06 Am (1)

零信任使用案例4：監控/審計

NGINX 日誌/指標可匯出至各種第三方供應商，包括Splunk、Prometheus/Grafana、雲端提供者（AWS CloudWatch 和Azure Monitor Logs）、Datadog、ELK 堆疊等。

透過NGINX Instance Manager 或NGINX SaaS，您可以原生監控NGINX 指標和日誌。 NGINX Plus API 支援可靈活地將指標匯出到任何接受JSON 的第三方工具。例如，在第一篇文章中，您可將NGINX Plus API 指標匯出到我們的原生即時儀表板中。 （請參閱本系列第一篇文章，以了解更多有關原生即時儀錶板的資訊。） 

無論選擇哪種工具，監控/稽核IT 系統產生的資料都是了解和最佳化應用的關鍵。

結語

雲端供應商提供了一種便捷的方法來將Kubernetes Service 暴露到網路上。只需建立Kubernetes service 類型LoadBalancer，外部用戶即可透過公共入口點連接到您的服務。但雲端負載平衡器只能實現基本的TCP/HTTP 負載平衡。因此，在將環境擴展到不同區域的多個叢集時，您可為NGINX Plus 配置許多零信任功能。在本系列文章的下一篇中，我們將對此進行詳細介紹。 

文章來源：DevCentral

標籤