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

[编辑——本文摘自我们的综合电子书《使用 F5 NGINX 管理 Kubernetes 流量》： 实用指南。 今天免费下载。]

随着组织规模的扩大，Kubernetes 中的开发和运营工作流程变得更加复杂。 团队共享 Kubernetes 集群和资源通常比每个团队都拥有自己的集群更具成本效益，并且更安全。 但是，如果团队不能以安全的方式共享这些资源，或者黑客利用您的配置，您的部署可能会受到严重损害。

网络和资源级别的多租户实践和命名空间隔离有助于团队安全地共享 Kubernetes 资源。 您还可以通过按租户隔离应用来显著减少违规的程度。 这种方法有助于提高弹性，因为只有特定团队拥有的应用的子部分会受到损害，而提供其他功能的系统仍然完好无损。

NGINX Ingress Controller 支持多种多租户模型，但我们看到两种主要模式。 基础设施服务提供商模式通常包括具有物理隔离的多个 NGINX Ingress Controller 部署，而企业模式通常使用具有命名空间隔离的共享 NGINX Ingress Controller 部署。 在本节中，我们将深入探讨企业模式；有关运行多个 NGINX Ingress Controller 的信息，请参阅我们的文档。

使用 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 配置的日常更改。 它们仅负责部署 NGINX Ingress Controller 和向外部公开部署的 Kubernetes服务。 然后，开发人员可以在指定的命名空间内部署应用，而无需管理员的参与。 开发人员负责管理 TLS 机密、定义域名的负载平衡配置以及通过创建 VirtualServer 或标准Ingress资源来公开他们的应用。

为了说明该模型，我们复制了示例bookinfo应用（最初由 Istio 创建），其中包含两个子域a.bookinfo.com和b.bookinfo.com ，如下图所示。 一旦管理员在nginx-ingress命名空间（以绿色突出显示）中安装并部署 NGINX Ingress Controller，DevA（粉色）和 DevB（紫色）团队就会创建自己的 VirtualServer 资源并在其命名空间（分别为A和B ）内部署隔离的应用。

DevA 和 DevB 团队为他们的域设置了 Ingress 规则，以将外部连接路由到他们的应用。

Team DevA 应用以下 VirtualServer 资源对象来为A命名空间中的a.bookinfo.com域公开应用。

类似地，DevB 团队应用以下 VirtualServer 资源来公开B命名空间中b.bookinfo.com域的应用。

实施受限自助服务

在受限的自助服务模型中，管理员配置 VirtualServer 资源以将进入集群的流量路由到适当的命名空间，但将命名空间中应用的配置委托给负责的开发团队。 每个这样的团队仅负责在 VirtualServer 资源中实例化的应用子路由，并使用 VirtualServerRoute 资源来定义流量规则并在其命名空间内公开应用程序子路由。

如图所示，集群管理员在nginx-ingress命名空间（以绿色突出显示）中安装并部署 NGINX Ingress Controller，并定义一个 VirtualServer 资源，该资源引用 VirtualServerRoute 资源定义设置基于路径的规则。

此 VirtualServer 资源定义设置了两个基于路径的规则，这两个规则引用了两个子路由/productpage-A和/productpage-B 的VirtualServerRoute 资源定义。

然后，负责命名空间A和B中的应用程序的开发团队定义 VirtualServerRoute 资源以在其命名空间内公开应用子路由。 团队按命名空间隔离，并仅限于部署由管理员提供的 VirtualServer 资源设置的应用程序子路由：

• 团队 DevA（图中粉色）应用以下 VirtualServerRoute 资源来公开管理员为/productpage-A设置的应用程序子路由规则。

• Team DevB（紫色）应用以下 VirtualServerRoute 资源来公开管理员为/productpage-B设置的应用子路由规则。

有关可在 VirtualServer 和 VirtualServerRoute 资源中配置的功能的更多信息，请参阅NGINX Ingress Controller 文档。

笔记： 您可以使用可合并的 Ingress 类型来配置跨命名空间路由，但是在受限的自助服务委派模型中，与 VirtualServer 和 VirtualServerRoute 资源相比，该方法有三个缺点：

1. 它的安全性较差。
2. 随着您的 Kubernetes 部署变得越来越大、越来越复杂，它变得越来越容易被意外修改，因为可合并的 Ingress 类型不会阻止开发人员为其命名空间内的主机名设置 Ingress 规则。
3. 与 VirtualServer 和 VirtualServerRoute 资源不同，可合并 Ingress 类型不允许主（“master”）Ingress 资源控制“minion”Ingress 资源的路径。

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

您可以使用 Kubernetes 基于角色的访问控制 (RBAC) 根据分配给用户的角色来规范用户对命名空间和 NGINX Ingress 资源的访问。

例如，在受限的自助服务模型中，只有具有特殊权限的管理员才能安全地访问 VirtualServer 资源 - 因为这些资源定义了 Kubernetes 集群的入口点，误用可能导致整个系统中断。

开发人员使用 VirtualServerRoute 资源为他们拥有的应用路由配置 Ingress 规则，因此管理员设置 RBAC 策略，允许开发人员仅创建这些资源。 如果他们需要进一步规范开发人员的访问，他们甚至可以将该权限限制在特定的命名空间内。

在完全自助服务模式下，可以安全地授予开发人员访问 VirtualServer 资源的权限，但管理员可能会将该权限限制在特定的命名空间内。

有关 RBAC 授权的更多信息，请参阅Kubernetes 文档。

添加策略

NGINX 策略资源是另一种支持分布式团队在多租户部署中配置 Kubernetes 的工具。 策略资源支持使用OAuth和OpenID Connect (OIDC) 进行身份验证、速率限制和 Web应用防火墙 (WAF) 等功能。 Policy资源在VirtualServer和VirtualServerRoute资源中引用，在Ingress配置中生效。

例如，负责集群中身份管理的团队可以定义JSON Web Token (JWT) 或 OIDC 策略，如下所示，使用 Okta 作为 OIDC 身份提供者 (IdP)。

NetOps 和 DevOps 团队可以使用 VirtualServer 或 VirtualServerRoute 资源来引用这些策略，如本例所示。

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

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

这篇文章摘录自我们的综合电子书《使用 NGINX 管理 Kubernetes 流量》： 实用指南。 今天免费下载。

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