关于kubernetes:使用-NGINX-在-Kubernetes-中实现多租户和命名空间隔离

原文作者：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 既反对规范 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 资源相比有三个毛病：

不太平安。
因为可合并的 Ingress 类型不会阻止开发人员在其命名空间内为主机名设置 Ingress 规定，随着 Kubernetes 部署规模和复杂度的日益减少，它将越来越容易受到篡改。
与 VirtualServer 和 VirtualServerRoute 资源不同，可合并的 Ingress 类型不容许主 (“master”) Ingress 资源管制“minion”Ingress 资源的门路。

您能够应用 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

关于kubernetes:使用-NGINX-在-Kubernetes-中实现多租户和命名空间隔离

应用 NGINX Ingress Controller 进行委派

施行齐全自助服务

施行受限自助服务

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

增加策略