使用 NGINX Controller 进行更安全的配置管理

在过去的一年里，通过与客户的交流，我们注意到一些反复出现的主题促使他们评估诸如NGINX Controller之类的编排产品：

• 复杂性——管理、维护、验证和应用来自不同来源的大量单独的配置对象并不容易。
• 脆弱性——扩大规模可以快速发生，通常是为了响应某个事件。 有时它是战略性的，但正如每个运营部门的情况一样，它是无计划的和有机的。
• 安全性——在部署生产之前避免错误和发现问题是敏捷方法的基石。 它们还有助于减轻复杂性和脆弱性。

这些并不是客户首次部署应用时通常面临的问题。 相反，随着时间的推移，它们会出现，应用变得成功并且需要扩大规模。 我们发现，扩展——或者更准确地说，无计划的扩展——是上述问题的常见根源。

幸运的是，NGINX Controller 配置对象模型解决了所有三个问题：

• 它将所有可能影响特定NGINX Plus实例集的配置组件集中在一个位置，从而降低了部署复杂性。
• 它允许团队在将配置投入生产之前对其进行验证和测试，从而降低脆弱性，使其更容易快速失败并确保生产用户流量保持畅通。
• 由于它具有高度的灵活性，因此可以提高安全性。 配置对象模型不会强迫您调整流程来适应模型，而是旨在与您的业务工作流程和职责分工保持一致 - 您可以根据需要授予各个业务部门对配置元素的适当所有权。

控制器配置对象

让我们更深入地了解一些关键的配置对象，以便您更好地了解控制器模型的工作原理。

环境

在大多数组织中，软件在发布之前要经过多个阶段：开发、用户验收、预生产、生产和其他质量检查阶段。 这些阶段对应于称为环境的 NGINX 控制器对象。

环境是控制器内配置元素的隔离区域。 它通常是定义基于角色的访问控制 (RBAC) 的级别。 环境可以在各个阶段携带相同的配置工件，同时用最小的更改替代目标服务器、数据中心和其他在环境之间通常不同的基础设施对象。

网关

网关是环境中的配置对象，通常用作定义如何向客户交付应用的顶层 - 例如主机名、协议和 TLS/SSL 行为等设置 - 尽管此类设置也可以在较低级别进行。 实际上，网络运营 (NetOps) 团队（管理边缘网络设备或 DMZ 的人员）通常拥有网关对象。 网关还采用了“放置”的概念，即如何链接控制器和接收配置并执行实际工作的 NGINX Plus 实例。

应用程序

下一级是应用程序配置对象，您可以在此开始对应用进行建模并对流量整形行为进行分组。 您可以根据需要使用任意数量或任意数量的应用程序来满足组织的需求。 唯一的要求是应用程序在环境中必须是唯一的。

成分

在应用程序中，组件描述了应用程序所需的流量整形行为。在最简单的情况下，给定路径名的所有流量都会发送到同一组服务器。 但是组件还控制更高级的造型，如标头操作、URL 重写、后端负载平衡行为、cookie 处理和其他设置。 主机名和 TLS/SSL 行为也可以在此级别定义。

总结

以下是配置对象之间关系的直观表示：

请注意，只有两个组与 Controller 交互 - 在本例中是两个开发团队， Referral和Transfers 。 实际上，我们知道参与应用交付和安全的人数可能要大得多，涵盖网络和安全（平台操作）、DevOps、应用程序开发等。 拥有最多知识的团队可以制定策略并构建符合最佳实践的自助服务工作流程，并为那些在横跨组织东部和西部数据中心位置的“开发”环境中使用应用程序、组件和网关的团队提供保护。

让我们以稍微不同的方式来看待这个问题，更多地从业务线（LOB）的角度来看待这个问题。 LOB 所有者越来越多地为现代应用程序做出应用决策。

下图说明了一个更真实的场景，其中包括更大的用户池，其中包括各种 LOB 团队和负责管理所有证书续订的个人 Shawn。

现在，我们有更多的个人参与者和管道影响最终的数据流。

当每个单独的管道从源代码控制（如 GitHub）移动到控制器的各种对象更改时，配置对象会在控制器端进行验证，然后与任何相关对象结合，然后将更改推送到 NGINX Plus 实例。

这就是 Controller 帮助使配置管理更安全的方式——通过确保最新的更改与以前的设置以及其他应用和 LOB 所有者的设置兼容。

我们意识到，在实践中，应用于单个 NGINX Plus 实例的所有配置都必须是可行的 - 但设置不能相互冲突、重叠或冲突。 提前发现冲突并通知提供每个单独组件配置的人员非常重要。

在上面的例子中，当推荐组件尝试使用转移组件已经实现的相同正则表达式模式时，就会立即捕获路径冲突，并且可以在推荐团队尝试在生产中部署此配置之前很久就收到通知 - 避免与配置错误相关的许多麻烦。

关于证书，Shawn 可以通过 Controller 的 RBAC 功能立即实施证书更改。 网关和组件的维护者只需要引用正确的证书，Shawn 就可以在自己的生命周期内自信地管理这些证书。 如果 Shawn 在 Controller 中更新证书，则会将其推送到正确的实例，而不会出现与证书过期相关的恐慌。

现在 NGINX Controller 拥有了所有配置对象以及与一个或多个 NGINX Plus 实例的 Placement 关联，它可以执行最后的步骤：应用配置。

安全实践

最后，使用 Controller 进行配置管理的目标是在正确的位置对正确的 NGINX Plus 实例应用正确的配置——确保应用程序、组件、网关以及所有相关证书和实例都正确配置，从而实现更安全、更具可扩展性的部署。

此最终验证是 Controller 使之更容易、更安全的配置管理流程的最后部分。 当将整个配置应用于具有某些相关对象更改的 NGINX Plus 实例时（例如作为代理部署的 NGINX Plus 的 Web 工作负载组中的会话持久性），将对整个配置进行验证，以确保实例与所需配置兼容。 如果满足该条件，则应用该配置。 为了最后的安全，如果在应用配置时出现任何问题，控制器将恢复到以前的配置。

除了确保配置符合要求之外，在应用新配置时，Controller 还可以利用高级 NGINX 功能（例如会话耗尽），从而保证站点在变化过程中保持可用性和性能。

对于运营团队来说，上面概述的概念和工作流程设计有助于 NGINX Controller 围绕配置管理提供的安全性。 这些保障措施有助于协调工作流程和使用现代应用程序的各个团队，同时也支持业务需求。

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