MSE Nacos 配置变更审计平台使用指南

作者：孙立（涌月）、邢学超（于怀）、李艳林（彦林）

配置审计平台简介

Nacos [ 1] 作为一款业界主流的微服务注册中心和配置中心，管理着企业核心的配置资产，由于配置变更的安全和稳定诉求越来越高，因此我们提供了安全和可追溯性保障机制。

配置变更的途径主要包括控制台手动发布和使用 Nacos SDK 客户端等方式，为了配置变更的安全性，我们需要对这两种变更进行变更操作的通知和追溯；其中既包括这些变更操作的变更责任人、责任机器的追踪，也包括变更操作对于相关方的通知和告警。

配置变更审计平台核心目标

从变更内容方面，配置变更动作可分为配置的发布、删除、导入、修改等；从变更渠道划分，Nacos 配置变更可分为 在控制台进行的手动操作、使用 Nacos SDK 进行的操作。配置变更发生之后，我们需要进行变更的详细审计，其中主要包括呈现配置的变更细节、变更之后的消息通知。

由此可见，配置变更的目标主要是在配置变更后进行相应的附加处理，来提升配置的可靠性、精准性，从而提升系统整体的安全性、可用性。为了提供给用户一个完善的配置变更审计平台，我们在审计平台中提出了以下几个配置变更的审计点：

• 配置变更操作责任人审计：

  在 MSE 中添加配置变更的操作责任人的信息，方便客户追溯配置变更的具体执行者；而对于未开启鉴权，未留下用户信息的用户，MSE Nacos 会将配置变更的来源 IP 记录下来，并且将其暴露给用户，从而保证整个审计链路的完整性和可追溯性；

• 配置变更影响面审计：

  当有多个微服务应用监听该配置时，我们需要记录下有哪些应用和机器监听了该配置，当配置内容发生变化，我们需要将其推送行为、推送成功与否、是否影响业务等信息在变更审计平台上呈现给用户；

• 配置变更内容审计：

  对所发布配置的内容进行记录，便于用户追溯配置历史的版本，以及每个历史版本的更新日期、所属应用、变更内容；

• 配置变更通知和告警：

  在配置变更（含发布、修改、导入、删除操作）之后，配置使用水位的实时监控以及配置使用水位超过阈值之后的告警，能够保证用户的及时感知配置的变化情况。

配置变更审计平台原理

如下图所示，配置变更审计平台会将用户的变更操作完整记录，并且通过配置操作人追溯、推送轨迹、配置历史版本审查、变更通知及告警等功能向用户透出。

例如，当用户组织内，某变更操作执行人 A 发起“配置变更 1”操作时，MSE 会将其操作内容和影响面做完整的记录，如“A 执行了配置变更1操作，变更内容为 XXX，该配置监听者及可能的受影响者为 C”。这些信息会通过配置操作人追溯大盘、配置操作影响面追溯大盘等，统一汇总到变更的审计人 E；同时，审计人 E 也可以通过配置使用水位监控观测到配置中心当前的整体使用情况，当配置的使用量超出既定阈值时，MSE 会通过告警信息等方式将风险透出给配置变更审计者。

由此，当用户组织内部的变更审计人需要对该变更进行审计和追溯时，便可以通过 MSE 配置变更审计平台，完整地看到该变更发行时间点、操作人、操作内容、影响面等各种信息，便于其进行团队和研发进度管理，界定风险责任。

配置操作人追溯

MSE Nacos 配置变更操作人追溯作为配置变更平台最主要的功能，用户可以在该追溯界面查看看到历次配置变更的详情和变更操作的责任人信息。

如下图所示，该功能在记录和呈现配置的操作细节时，对于展示内容设置了多个优先级：

• 当变更的操作来源为用户手动在 MSE 控制台进行发布变更时，配置变更责任人的内容为用户的账号信息，其中：

<!---->

• • 若用户使用阿里云主账号登录，则记录并呈现主账号的 UID；
  • 若用户使用其所属的子账号登录，则记录并呈现登录使用的子账号的 UID。

<!---->

• 当变更的操作来源为用户使用 Nacos 的 Client 来进行配置的增删改查等操作时，MSE 会判断操作源是否携带身份信息：

<!---->

• • 如果该操作源携带了身份信息，则将其识别并展示出来；
  • 否则，MSE 会自动识别该操作源的来源 IP 并展示在配置操作人追溯列表中，便于配置审计人更加准确和全面地履行审计职责。

配置变更推送轨迹

同时，MSE Nacos 配置变更审计平台也呈现了配置中心的推送轨迹。如下图所示，在推送轨迹页面，用户可以通过推送轨迹查询某配置相关的变更事件，也可以根据 IP 查询所有和该 IP 地址相关的推送轨迹。其中配置中心配置变更和发布的各种详细问题都在推送轨迹界面有所展示，例如：

• 配置发布异常；
• 配置修改完发现某台机器不生效；
• 需要查看配置中心变更及推送事件。

其中，变更事件、DataId、Group 分别表示分别表示本次配置变更事件类型、该配置变更事件的配置、该配置变更事件的配置所属分组。在“详情”列可以看到详情图标可以看到本次变更事件详细信息，点击详情列跳转按钮可以切换到配置维度查询的入口查询当前配置在该时间点的推送事件。

配置监控大盘及告警

同时，MSE Nacos 也提供了变更之后的配置监控页面，主要监测指标包括：

• 配置中心主要业务指标：配置数、配置监听者数；
• 配置中心访问量指标：配置中心 TPS、QPS、写 RT、读 RT；
• MSE 引擎整体的节点数、配置数、每秒查询数、每秒操作数和连接数等信息。

在这个监控大盘下，用户可以在配置变更之后，进行各项配置管理核心指标的校验，例如当配置管理业务上出现推送配置不及时时，可以通过读写 RT 指标快速定位当前配置中心的相应时间；

另外，在压测场景下，用户也可以通过该大盘进行配置数、配置监听者数、TPS 等指标的实时观测；

当配置数或配置使用水位超过既设阈值时，也会给配置变更的审计者发送报警信息。

配置变更审计最佳实践

下面介绍如何使用 MSE Nacos 提供的配置变更审计能力，并使用该能力增强配置变更的安全性和可追溯性。

整个最佳实践可以归纳为如下几个步骤：

1.开通微服务引擎 MSE

2.登录 MSE 控制台，并创建 Nacos 引擎实例

3.在 MSE Nacos 创建相关配置、修改相关配置并删除

4.在配置中心控制台查看配置操作人及配置变更历史

5.使用 Nacos Client SDK 进行配置创建和删除

6.在配置中心控制台查看配置操作人及配置变更来源 IP

7.对配置中心使用情况配置告警，当配置使用水位超过某一阈值的时候，对用户发送通知

1. 开通微服务引擎 MSE

您可登录微服务引擎 MSE [ 1] ，查看并开通 MSE。

2. 登录 MSE 控制台，并创建 Nacos 引擎实例

登录微服务引擎 MSE 产品控制台，在左侧选项框中选择“注册配置中心”，点击“实例列表”，确定 region 后，选择“创建实例”。

3. 在 MSE Nacos 创建相关配置、修改相关配置并删除重建

您可在 MSE Nacos 控制台界面手动创建配置，并做多次修改、删除及重新创建等操作。

4. 在配置中心控制台查看配置操作人及配置变更历史

由下图可见，配置变更的操作人已经呈现，点击“查看”也可以看到历次配置变更的详情和变更之前的历史版本内容。

5. 使用 Nacos Client SDK 进行配置创建和删除

可参考 Nacos Client SDK 使用指南 [ 2] 进行 Nacos Client SDK 的依赖安装，并进行配置创建、修改、删除等操作。

6. 在配置中心控制台查看配置操作人及配置变更来源 IP

可以看到，使用 Nacos Client SDK 进行操作，即使在未开启鉴权的情况下，也留下了发布来源 IP。MSE Nacos 用户可以通过该 IP 追溯到配置变更的来源信息。

7. 添加配置用量告警

此处我们添加配置水位大于 90% 时的告警，当配置使用水位超过该阈值时，会通过短信、电话等方式通知到配置变更的审计人。

🔔 注意：

1. 对于 Nacos Client SDK1.X（HTTP 版本），由于其IP信息并未携带在 HTTP 报文中，MSE Nacos 并未对其进行存储；若使用该 SDK 进行配置发布，本着配置操作人来源信息的准确性原则，并未透出该信息；
2. 使用 Nacos Client SDK 发布，控制台可查看 IP 的功能支持需升级至 Nacos2.2.3.2 版本。但目前该版本尚在全网灰度发布中，预计 2 月中旬将全部灰度完毕，如果发现该版本尚未灰度至您所在地域，可以通过 MSE 工单解决。

MSE Nacos 配置变更审计平台未来展望

对于配置变更的发生位置主要分为变更前和后，上述功能主要发生在变更后。而在未来，我们将一方面对于配置变更发生之前的问题进行拦截和处理，协助 MSE 用户进行配置变更的防错性措施，主要包括文件检查、参数校验等，即防御式开发；另一方面继续保障配置变更发生之后的确认和验收性工作，保证变更的正确发生。

MSE Nacos 配置变更审计平台将致力于在配置变更的整个生命周期进行相应的附加处理，来提升配置的可靠性、精准性、安全性。我们主要提出三种未来将添加进入配置变更审计平台的功能：

文件内容校验和审批

此功能为事前校验、预防性的配置变更审计功能，在配置变更发生之前，MSE Nacos 将发起一个审批流程，交由用户组织内部的研发管理者或运维管理者判断文件上传的内容是否符合要求；

具体的落地方案是通过 MSE 控制台进行校验、预防；另外，为了防止存在偶发的漏放情况，MSE 将允许用户设计多层次的审批结构加强校验防护。

变更内容白名单与黑名单

此类需求也为事前拦截、预防性的需求，在配置变更发生之前，判断本次变更的具体内容是否在白名单或者黑名单（比如是否在 yaml 文件的指定 Key 范围）之内，来保证更加精细粒度的权限管理。

例如，当运维 A 只被授权修改某配置文件 yaml 中的“useLocalCache”字段时，如果该配置变更审批修改了其他的字段，则会被黑名单拦截；而如果该变更只局限于该字段，则会被放行。即，权限受限的操作人只允许规定的配置内容的修改和变更。

基于 WebHook 的配置变更通知

此类需求为事后感知类的需求，当配置变更发生之后，将配置变更的情况通过多渠道及时推送至客户，让用户明确所操作带来的后果是否符合预期。

现有的实现方案则是通过 listener 进行监听。但该方案缺点则是不便于清晰感知、同时需要用户进行二次开发，而采用 Webhook 方式，结合常用的办公应用，如钉钉，企业微信，则可将变更情况推送至群\个人，更加清晰地感知，便捷地接受。

相关链接：

[1] Nacos/微服务引擎 MSE

https://www.aliyun.com/product/aliware/mse?spm=5176.28508143....

[2] Nacos Client SDK 使用指南

https://nacos.io/docs/v2/guide/user/sdk/