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

NGINX | 2022年6月14日

[编者按：本文摘自我们的综合电子书《使用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 Service。随后，开发人员无需管理员参与，即可在分配的命名空间内部署应用。开发人员负责管理TLS Secret、定义域名的负载均衡配置，并通过创建VirtualServer或标准Ingress资源来公开其应用。

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

Kubernetes集群中的完全自助服务拓扑：管理员只需部署并公开NGINX Ingress Controller；随后，开发人员可在分配的命名空间内部署应用程序，无需管理员参与

DevA和DevB团队为各自的域设置Ingress规则，将外部连接路由到其应用。

DevA团队应用以下VirtualServer资源对象，以公开a.bookinfo.com域的应用，该域位于A命名空间中。

正在加载代码示例…

同样，DevB团队应用以下VirtualServer资源，以公开b.bookinfo.com域在B命名空间中的应用。

正在加载代码示例…

实施受限自助服务

在受限自助服务模式下，管理员通过配置VirtualServer资源，将进入集群的流量路由到相应的命名空间，同时将命名空间内应用的配置工作委托给负责这些应用的开发团队。每个团队仅负责其在VirtualServer资源中实例化的应用子路由，并使用VirtualServerRoute资源定义流量规则，以及公开其命名空间内的应用子路由。

Kubernetes集群中受限自助服务的拓扑图，其中管理员配置VirtualServer资源，但将应用配置委托给开发团队；开发团队使用VirtualServerRoute资源定义流量规则并公开应用子路由

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

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

正在加载代码示例…

负责命名空间A和B中应用的开发团队随后定义VirtualServerRoute资源，以公开各自命名空间中的应用子路由。各团队按命名空间相互隔离，并且只能部署由管理员预置的VirtualServer资源所设定的应用子路由：

DevA团队（图中粉色部分）应用以下VirtualServerRoute资源，以公开管理员为/productpage-A设置的应用子路由规则。
正在加载代码示例…
DevB团队（紫色）应用以下VirtualServerRoute资源，以公开管理员为应用设置的子路由规则：/productpage-B。
正在加载代码示例…

如需详细了解可在VirtualServer和VirtualServerRoute资源中配置的功能，请参阅NGINX Ingress Controller文档。

注意：可以使用可合并的Ingress类型配置跨命名空间路由，但在受限的自助委派模型中，与VirtualServer和VirtualServerRoute资源相比，这种方法有三个缺点：

安全性较低。
随着Kubernetes部署规模扩大、复杂性增加，意外修改的风险也会随之上升，因为可合并的Ingress类型无法阻止开发人员为其命名空间内的主机名设置Ingress规则。
与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资源在Ingress配置中生效，需要在VirtualServer和VirtualServerRoute资源中引用这些资源。

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

正在加载代码示例…

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

正在加载代码示例…

NGINX Policy、VirtualServer和VirtualServerRoute资源协同支持分布式配置架构，使管理员能够轻松地将配置工作委派给其他团队。各团队可以跨命名空间组装模块，并以安全、可扩展且易于管理的方式配置NGINX Ingress Controller，以满足复杂的用例需求。