使用NGINX Controller实现更安全的配置管理

NGINX | 2021年9月02日

Brian Ehlert产品管理总监

过去一年中，通过与客户交流，我们发现有几个反复出现的主题，促使他们评估以下编排产品：NGINX Controller：

复杂性：管理、维护、验证和应用来自不同来源的大量独立配置对象并非易事。
脆弱性，扩展可能会迅速发生，通常是为了应对某个事件。有时这是战略性举措，但正如各个运维部门经常遇到的情况一样，扩展往往未经规划，而是自然形成的。
安全性：避免错误并在部署到生产环境之前发现问题，是敏捷方法的基石。这些做法还有助于降低复杂性和脆弱性。

客户在首次部署应用时通常不会遇到这些问题。相反，随着时间推移，当应用取得成功并需要扩展时，这些问题才会逐渐显现。我们发现，扩展，更准确地说，是计划外扩展，是上述问题的共同根源。

所幸，NGINX Controller配置对象模型可以解决上述三个问题：

它将可能影响一组特定NGINX Plus实例的所有配置组件集中在一个位置，从而降低部署复杂性。
它可以降低脆弱性，让团队能够在将配置投入生产环境之前进行验证和测试，从而更容易快速发现问题，并确保生产环境中的用户流量持续传输。
它有助于提升安全性，因为它具有高度灵活性。配置对象模型旨在与业务工作流和职责分工保持一致，无需调整流程来适应该模型；您可以根据需要，向不同业务部门授予对相应配置元素的适当所有权。

Controller配置对象

下面深入了解一些关键配置对象，以便更好地理解Controller模型的工作原理。

环境

在大多数组织中，软件在发布前会经历多个阶段：开发、用户验收、预生产、生产以及其他质量检查阶段。这些阶段对应于NGINX Controller中名为Environment的对象。

环境是Controller中配置元素的隔离区域。通常在环境级别定义基于角色的访问控制（RBAC）。环境可让相同的配置工件贯穿各个阶段，只需对目标服务器、数据中心以及其他通常因环境而异的基础设施对象进行少量替换。

网关

Gateway是Environment中的一种配置对象，通常作为顶层对象，用于定义向客户交付应用的方式，包括主机名、协议和TLS/SSL行为等设置，不过也可以在较低层级进行这些设置。实际使用中，Gateway对象通常由负责管理边缘网络设备或DMZ的网络运维（NetOps）团队管理。Gateway还采用“Placement”概念，用于将Controller与接收配置并执行实际工作的NGINX Plus实例关联起来。

应用

下一级是 App 配置对象，可在其中开始对应用进行建模，并对流量调节行为进行分组。您可以根据组织的需求使用任意数量的 App。唯一的要求是，每个 App 在其所属的 Environment 中必须具有唯一性。

组件

在App中，Components用于描述App所需的流量调度行为。最简单的情况是，将指定路径名的所有流量发送到同一组服务器。但Components还可控制更高级的流量调度，例如标头操作、URL重写、后端负载均衡行为、Cookie处理及其他设置。还可在此级别定义主机名和TLS/SSL行为。

融会贯通

下图直观展示了各配置对象之间的关系：

请注意，只有两个团队与Controller交互，在本例中是两个开发团队：Referral和Transfers。实际上，参与应用交付和安全工作的人员可能要多得多，涵盖网络和安全（Platform Ops）、DevOps、应用开发等领域。掌握专业知识的团队可以设置策略，并构建符合最佳实践的自助式工作流，为使用Apps、Components和Gateways的团队提供必要的约束。这些对象位于“Dev”环境中，该环境横跨组织的东部和西部数据中心。

让我们换个角度，从业务线（LOB）的视角来看。业务线负责人正越来越多地参与现代应用的相关决策。

下图展示了一个更贴近实际的场景，其中用户群体规模更大，包括各个业务线（LOB）团队，以及负责管理所有证书续订工作的Shawn。

显示多个团队协作使用NGINX Controller配置NGINX Plus实例的示意图

现在，有更多独立参与者和流水线会影响最终的数据流。

当各个管道处理从源代码控制系统（如GitHub）到Controller的各种对象变更时，Controller会验证配置对象，然后将其与所有相关对象合并，再将变更下发到NGINX Plus实例。

Controller 正是通过确保最新更改与先前设置以及其他应用和业务线（LOB）所有者的设置兼容，帮助提高配置管理的安全性。

我们认识到，在实际应用中，必须能够将所有配置应用于同一个NGINX Plus实例，但各项设置之间不得存在冲突、重叠或不兼容。提前发现冲突并通知负责提供各个组件配置的人员也很重要。

在上述示例中，当Referral组件尝试使用Transfers组件已实施的同一正则表达式模式时，系统会立即发现路径冲突，并可在Referral团队尝试将此配置部署到生产环境之前尽早通知他们，从而避免配置错误带来的诸多问题。

在证书管理方面，借助Controller的RBAC功能，Shawn可以立即实施证书变更。Gateway和Component的维护人员只需引用正确的证书，Shawn便可在证书的整个生命周期内放心地进行管理。如果Shawn在Controller中更新证书，更新后的证书会推送到正确的实例，从而避免证书过期带来的慌乱。

现在，NGINX Controller已包含所有配置对象，并已与一个或多个NGINX Plus实例建立Placement关联，因此可以执行最后一步：应用配置。

实践中的安全保障

归根结底，使用Controller进行配置管理的目标，是在正确位置的正确NGINX Plus实例上应用正确配置。确保Apps、Components、Gateways及所有相关证书和实例均得到正确配置，可提高部署的安全性和可扩展性。

这项最终验证是配置管理流程的最后一步，Controller让这一流程更简单、更安全。将完整配置应用到关联对象发生更改的NGINX Plus实例时，系统会对其进行验证。例如，对于部署为代理的NGINX Plus，Web工作负载组中的会话持久性发生更改时，系统会验证该实例是否与所需配置兼容。如果满足此条件，则应用该配置。为进一步确保安全，如果应用配置时出现任何故障，Controller会恢复到之前的配置。

除了确保配置通过验证外，Controller还可以在应用新配置时利用NGINX的高级功能（例如会话排空），确保网站在配置变更期间保持可用性和性能。

对于运维团队而言，上述概念和工作流设计有助于提升NGINX Controller配置管理的安全性。这些保障措施有助于协调工作流以及参与现代应用工作的各个团队，同时满足业务需求。

要试用NGINX Controller，请立即开始30天免费试用，或联系我们，讨论您的用例。