使用 NGINX 在 Kubernetes 中實現多租戶和名稱空間隔離

NGINX開源社群發表於2023-02-15
Nginx
原文作者：Amir Rawdat of F5
原文連結：使用 NGINX 在 Kubernetes 中實現多租戶和名稱空間隔離
轉載來源：NGINX 官方網站

NGINX唯一中文官方社群 ，盡在 nginx.org.cn

隨著企業規模的不斷擴大，Kubernetes 中的開發和運營工作流程也變得愈加複雜。與每個團隊都擁有自己的叢集相比，各個團隊之間共享 Kubernetes 叢集和叢集中資源的做法通常更經濟高效、更安全。但是，如果團隊無法以安全可靠的方式共享資源或者配置遭駭客利用，則可能會對部署的應用系統造成嚴重損害。

網路和資源級別的多租戶實踐和名稱空間隔離有助於團隊安全地共享 Kubernetes 資源。您還可以按照單租戶獨佔的方式隔離應用，從而顯著縮小攻擊的影響範圍。這種方法有助於提高彈性，因為只有特定團隊擁有的部分應用可能會受到損害，而提供其他功能的系統則完好無損。

NGINX Ingress Controller 支援多種多租戶模式，但最常見的主要是下列的兩種模式：

  • 基礎架構服務提供商模式通常指使用隔離的 NGINX Ingress Controller，透過物理基礎架構隔離來實現多租戶；
  • 企業模式指使用共享的 NGINX Ingress Controller 部署，透過名稱空間隔離來實現多租戶。

我們將在本節深入探討企業模式；有關執行多個 NGINX Ingress Controllers 的更多資訊，請參閱我們的文件。

使用 NGINX Ingress Controller 進行委派

NGINX Ingress Controller 既支援標準 Kubernetes Ingress 資源，也支援自定義 NGINX Ingress 資源，可提供更復雜的流量管理並配置控制任務委派給多個團隊。自定義資源為VirtualServer、 VirtualServerRoute、GlobalConfiguration、TransportServer及Policy。

藉助 NGINX Ingress Controller，叢集管理員可使用 VirtualServer 資源來配置 Ingress 域名（主機名）規則，將外部流量路由到後端應用，也可使用 VirtualServerRoute 資源將特定 URL 的管理委派給應用所有者和 DevOps 團隊。

在 Kubernetes 叢集中實現多租戶時，有兩種模型可供您選擇完全自助服務和受限自助服務。

實施完全自助服務

在完全自助服務模型中，管理員不參與 NGINX Ingress Controller 所監控的 Ingress 資源的日常更改。他們只負責部署 NGINX Ingress Controller 及如何將部署的 KubernetesService暴露給外部。之後，開發人員在指定的名稱空間內部署應用，而無需管理員參與。開發人員負責管理 TLS 金鑰，定義域名的負載均衡配置，並透過建立 VirtualServer 或標準的Ingress資源暴露其應用。

為了闡釋這個模型，我們使用了bookinfo示例應用（最初由 Istio 建立）和兩個子域名a.bookinfo.com和b.bookinfo.com，如下圖所示。管理員在nginx-ingress名稱空間（綠色）中安裝和部署 NGINX Ingress Controller 之後，DevA（粉色）和 DevB（紫色）團隊就會建立自己的 VirtualServer 資源，並將應用隔離在他們的名稱空間（分別為A和B）中。

DevA 和 DevB 團隊為他們的域設定了 Ingress 規則，以便將外部連線路由到他們的應用。

DevA 團隊應用以下 VirtualServer 資源物件，以a.bookinfo.com域名將A名稱空間中的應用暴露出去。

 1 apiVersion: k8s.nginx.org/v1
 2 kind: VirtualServer
 3 metadata:
 4   name: bookinfo
 5   namespace: A
 6 spec:
 7   host: a.bookinfo.com
 8   upstreams:
 9   - name: productpageA
10     service: productpageA
11     port: 9080
12   routes:
13   - path: /
14     action:
15       pass: productpageA

同樣，DevB 團隊應用以下 VirtualServer 資源，以b.bookinfo.com域名將 B 名稱空間中的應用暴露出去。

1 apiVersion: k8s.nginx.org/v1
2 kind: VirtualServer
3 metadata:
4   name: bookinfo
5   namespace: B
6 spec:
7   host: b.bookinfo.com
8   upstreams:
9   - name: productpageB
10     service: productpageB
11     port: 9080
12   routes:
13   - path: /
14     action:
15       pass: productpageB

實施受限自助服務

在受限自助服務模型中，管理員配置 VirtualServer 資源，將進入叢集的流量路由到適當的名稱空間，但將名稱空間中的應用配置任務委派給負責任的開發團隊。每個團隊只負責其在 VirtualServer 資源中例項化的應用子路由，使用 VirtualServerRoute 資源來定義流量規則並將應用子路由暴露在其名稱空間中。

如圖所示，叢集管理員在nginx-ingress名稱空間（綠色突出顯示）中安裝和部署了 NGINX Ingress Controller，並將一項 VirtualServer 資源定義為根據 VirtualServerRoute 資源定義設定基於路徑的規則。

該 VirtualServer 資源定義設定了兩條基於路徑的規則，這些規則關聯了需要透過 VirtualServerRoute 資源定義的兩條子路由/productpage-A和/productpage-B。

 1 apiVersion: k8s.nginx.org/v1
 2 kind: VirtualServer
 3 metadata:
 4   name: example
 5 spec:
 6   host: bookinfo.example.com
 7   routes:
 8   - path: /productpage-A
 9     route: A/ingress 
10   - path: /productpage-B
11     route: B/ingress

然後，負責名稱空間A和B中應用的開發人員團隊定義 VirtualServerRoute 資源，將其名稱空間中的應用透過子路由暴露出去。這些團隊透過名稱空間隔離，並且只能部署由管理員提供的 VirtualServer 資源設定的應用子路由：

  • DevA 團隊（圖中粉色部分）應用下面的 VirtualServerRoute 資源，暴露管理員設定的應用子路由規則路徑/productpage-A。
 1 apiVersion: k8s.nginx.org/v1
 2 kind: VirtualServerRoute
 3 metadata:
 4   name: ingress 
 5   namespace: A
 6 spec:
 7   host: bookinfo.example.com
 8   upstreams:
 9   - name: productpageA
10     service: productpageA-svc
11     port: 9080
12   subroutes:
13   - path: /productpage-A 
14     action:
15       pass: productpageA
  • DevB 團隊（圖中紫色部分） 應用下面的 Virtual ServerRoute 資源，暴露管理員設定的應用子路由規則路徑/productpage-B。
 1 apiVersion: k8s.nginx.org/v1
 2 kind: VirtualServerRoute
 3 metadata:
 4   name: ingress 
 5   namespace: B
 6 spec:
 7   host: bookinfo.example.com
 8   upstreams:
 9   - name: productpageB
10     service: productpageB-svc
11     port: 9080
12   subroutes:
13   - path: /productpage-B 
14     action:
15       pass: productpageB

如欲詳細瞭解您可以在 VirtualServer 和 VirtualServerRoute 資源中配置的特性，請參閱NGINX Ingress Controller 文件。

注：您可以使用可合併的 Ingress 型別來配置跨名稱空間的路由，但在受限自助服務委派模型中，這種方法與 VirtualServer 和 VirtualServerRoute 資源相比有三個缺點：

  1. 不太安全。
  2. 由於可合併的 Ingress 型別不會阻止開發人員在其名稱空間內為主機名設定 Ingress 規則，隨著 Kubernetes 部署規模和複雜度的日益增加，它將越來越容易遭到篡改。
  3. 與 VirtualServer 和 VirtualServerRoute 資源不同，可合併的 Ingress 型別不允許主 (“master”) Ingress 資源控制 “minion” Ingress 資源的路徑。

在受限自助服務模型中利用 Kubernetes RBAC

您可以使用 Kubernetes 的基於角色的訪問控制 (RBAC) 功能，根據分配給使用者的角色來管理使用者對名稱空間和 NGINX Ingress 資源的訪問。

舉例來說，在受限自助服務模型中，只有具有特殊許可權的管理員才能安全地訪問 VirtualServer 資源——因為這些資源定義了 Kubernetes 叢集的入口點，如果遭到濫用，可能會導致系統中斷。

開發人員使用 VirtualServerRoute 資源為他們擁有的應用路由配置 Ingress 規則，因此管理員將 RBAC 策略設定為開發人員只能建立這些資源。如果需要進一步規範開發人員的訪問許可權，他們甚至可以將該訪問許可權限制到特定的名稱空間。

在完全自助服務模型中，開發人員可以安全地訪問 VirtualServer 資源，但管理員也可能會將該訪問許可權限制到特定的名稱空間。

如欲瞭解 RBAC 授權的更多資訊，請參閱Kubernetes 文件。

新增策略

NGINX Policy 資源也支援分散式團隊在多租戶部署中配置 Kubernetes。Policy 資源支援OAuth和OpenID Connect(OIDC) 身份驗證、速率限制和 Web 應用防火牆 (WAF) 等功能。Policy 資源在 VirtualServer 和 VirtualServerRoute 資源中被引用，在 Ingress 配置中生效。

舉例來說，負責叢集中身份管理的團隊可以定義JSON Web Token(JWT) 或 OIDC 策略，如下所示，使用 Okta 作為 OIDC 身份認證提供商 (IdP) 的策略。

apiVersion: k8s.nginx.org/v1
kind: Policy
metadata:
  name: okta-oidc-policy
  spec:
   oidc:
    clientID: client_id
    clientSecret: okta-oidc-secret
    authEndpoint: https://your_okta_domain/oauth2/v1/authorize
    tokenEndpoint: https://your_okta_domain/oauth2/v1/token
    jwksURI: https://your_okta_domain/oauth2/v1/keys

NetOps 和 DevOps 團隊可以使用 VirtualServer 或 VirtualServerRoute 資源來引用這些策略，如本示例所示。

NGINX Policy、VirtualServer 和 VirtualServerRoute 資源可進一步完善分散式配置架構，管理員可輕鬆地將配置委派給其他團隊。團隊可以跨名稱空間組裝模組，並以安全、可擴充套件和可管理的方式為 NGINX Ingress Controller 配置複雜的用例。

有關 Policy 資源的更多資訊，請參閱NGINX Ingress Controller 文件。

NGINX唯一中文官方社群 ，盡在 nginx.org.cn

更多 NGINX 相關的技術乾貨、互動問答、系列課程、活動資源：

開源社群官網：https://www.nginx.org.cn/
微信公眾號：https://mp.weixin.qq.com/s/XVE5

相關文章