使用 NGINX 在 Kubernetes 中实现多租户和命名空间隔离

随着企业规模的不断扩大，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 及如何将部署的 Kubernetes Service 暴露给外部。之后，开发人员在指定的命名空间内部署应用，而无需管理员参与。开发人员负责管理 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 资源来引用这些策略，如本示例所示。

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: bookinfo-vs
spec:
  host: bookinfo.example.com
  tls:
    secret: bookinfo-secret
  upstreams:
  - name: backend
    service: productpage
    port: 9080
  routes:
  - path: /
    policies:
    - name: okta-oidc-policy
    action:
      pass: backend

NGINX Policy、VirtualServer 和 VirtualServerRoute 资源可进一步完善分布式配置架构，管理员可轻松地将配置委派给其他团队。团队可以跨命名空间组装模块，并以安全、可扩展和可管理的方式为 NGINX Ingress Controller 配置复杂的用例。

有关 Policy 资源的更多信息，请参阅 NGINX Ingress Controller 文档。

立即体验基于 NGINX Plus 的 NGINX Ingress Controller 的 30 天免费试用版，或者联系我们讨论您的用例。