Nacos配置安全最佳实践

前言

---

配置管理作为软件开发中重要的一环，肩负着连接代码和环境的职责，能很好的分离开发人员和维护人员的关注点。

Nacos 的配置管理功能就很好地满足了云原生应用对于配置管理的需求：既能做到配置和代码分离，也能做到配置的动态修改。

在 1月份，Nacos 出了一个安全漏洞，外部用户能够伪装为 Nacos-server 来获取/修改配置（ https://github.com/alibaba/nacos/issues/4593 ）。确认问题后，Nacos 火速修复了漏洞，而阿里云的微服务引擎（MSE）也已在 1月末将修复方案反向移植到 MSE 上的 Nacos 实例上。

在本文中，我们将会从全局视角入手，讨论如何才能保证 Nacos 配置的安全性（security），即如何保证配置信息不被恶意用户获取或者泄漏。

Nacos 配置架构

---

Nacos 配置部分的整体架构如下：

对于上图中的每一条链路，都需要考虑有没有两个基本的安全动作：认证（Identification）和鉴权（Authentication）。

从上图可以看到，配置信息可能的泄漏方式有：

• 通过 Nacos-client 获取配置。
• 通过控制台获取配置。
• 通过服务器之间的通信协议获取配置。
• 直接访问持久化层（比如 DB）获取配置。
  

可能的泄漏点如下：

	认证	鉴权
Nacos 客户端	未登录用户通过客户端获取/修改配置	用户通过客户端获取/修改了未授权的配置
配置控制台	未登录用户通过控制台获取/修改配置	用户通过控制台获取/修改了未授权的配置
Nacos 集群内	用户伪装为 Nacos 集群获取/修改配置	不需要
持久化层	用户直接查 DB，获取/修改配置	不需要

Nacos 客户端场景的认证和鉴权

---

在 Nacos 客户端尝试从服务端获取配置时，服务端需要确认客户端的身份，并确认该身份有权限获取配置。

开源版本的 Nacos

在默认的 Nacos server 配置中，不会对客户端鉴权，即任何能访问 Nacos server 的用户，都可以直接获取 Nacos 中存储的配置。比如一个黑客攻进了企业内网，就能获取所有的业务配置，这样肯定会有安全隐患。

所以需要先开启 Nacos server 的鉴权。在 Nacos server 上修改 application.properties 中的 nacos.core.auth.enabled 值为 true 即可：

nacos.core.auth.enabled=true

如上设置后，Nacos 客户端获取配置时，需要设置上对应的用户名和密码，才能获取配置：

String serverAddr = "{serverAddr}";
Properties properties = new Properties();
properties.put("serverAddr", serverAddr);
properties.put("username","nacos-readonly");
properties.put("password","nacos");
ConfigService configService = NacosFactory.createConfigService(properties);

上面讲了如何认证用户，即如何确定现在是哪一个用户在访问，但还需要识别用户的权限，当用户访问没有权限获取对应配置的时候，比如库存服务尝试获取支付服务的配置时，就会失败。

我们可以在开源的 Nacos 控制台上创建用户、设置权限。步骤如下：

首先，访问 localhost:8848/nacos 并登录，在 权限控制->用户列表 页面，添加用户：

在 权限控制->角色管理，绑定用户和角色：

给对应角色添加权限，在 权限控制->权限管理 页面，添加权限：

经过如上配置后，readonly-user 就只能访问 public 命名空间下的配置了。

阿里云 MSE-AK/SK

对于小团队，用用户名和密码来做认证鉴权是足够的。但对于中大型团队，密码的定期更换、人员的频繁变动等，都会导致用户名和密码频繁变动。

这时，使用用户名和密码认证鉴权就需要频繁修改并发布应用。为了解决这个问题，Nacos 也提供了基于 AK/SK 的认证方案、ECS关联RAM角色的方案，可以避免用户名和密码修改导致的频繁发布问题。

以阿里云 MSE 为例，阿里云用户已经普遍使用了阿里云访问控制服务（RAM）作为权限系统，如果 MSE 和开源一样，使用用户名和密码实现认证和鉴权的话，那么用户就需要在 RAM 和 MSE Nacos 两个地方配置权限。这样既不方便用户权限的统一管理、审查，也给用户带来了不一致的体验。

所以 MSE（微服务引擎）提供了基于 AK/SK 的认证方式，操作示例如下：

首先，在 MSE 上申请一个 Nacos 实例（并记下实例 id），然后在 实例详情->参数设置 界面，将 ConfigAuthEnabled（配置鉴权）参数设置为 true，这样匿名用户就无法获取配置：

然后就可以在阿里云RAM系统上配置相关权限。RAM子账号的权限系统可以简单表示如下：

• 第一步：创建 RAM 权限策略如下：

图中，mse:Get*、mse:List*、mse:Query* 表示能读取配置，mse:* 表示所有权限，包括修改权限。

acs:mse:*:*:instance/${instanceId} 表示授权到实例级别，acs:mse:*:*:instance/${instanceId}/${namespaceId} 表示授权到命名空间级别。

• 第二步：创建用户并赋予权限：

填写用户名称：

然后获取到用户的 AK/SK：

给这个用户对应的权限：

• 最后，只需要在代码中添加 AK/SK 就可以了：

String serverAddr = "{serverAddr}";
Properties properties = new Properties();
properties.put("serverAddr", serverAddr);
properties.put(PropertyKeyConst.ACCESS_KEY, "${accessKey}");
properties.put(PropertyKeyConst.SECRET_KEY, "${secret}");
ConfigService configService = NacosFactory.createConfigService(properties);

经过如上配置，客户端在访问 MSE 上购买的 Nacos 实例的时候，MSE 会校验 AK 和签名，确认该用户是合法的用户，并校验权限，否则拒绝提供服务。

阿里云 MSE- 基于 ECS 的 Ram 角色认证

当然，在上面的使用方式中，还是要在初始配置（比如 srping-cloud-alibaba-nacos-config 中的 bootstrap.yml 文件）中配置 AK/SK。黑客入侵内网、或者源码泄漏时，也会存在 AK/SK 泄漏，导致配置信息泄漏的风险。

在这种情况下，推荐使用 ECS 关联的 RAM 角色来做认证。

ECS 关联 RAM 角色对应的授权模型如下：

上述的关键步骤在角色扮演。只有关联了 RAM 角色的云服务器，才能成功扮演角色，从而获取操作 MSE Nacos 实例的权限。

如果黑客只获取了代码，也无法成功扮演 RAM 角色，无法操作 MSE Nacos 实例。如果机器被攻破，那也能在阿里云控制台上取消云服务器关联的角色，及时止损。

具体的操作步骤如下：

• 第一步，创建 MSE Nacos 实例，并创建对应的权限策略（上文有说明，此处不赘述）。

• 第二步，创建 RAM 角色并授权。

创建 RAM 角色：

创建角色后，为该角色添加对应的权限策略：

• 第三步，将该角色和 ECS 关联：

在对应的 ECS 详情页面，点击 授予/收回 RAM 角色：

选择对应的角色并授予：

• 最后一步，在代码中 指定 RAM 角色 即可：

String serverAddr = "{serverAddr}";
Properties properties = new Properties();
properties.put("serverAddr", serverAddr);
properties.put(PropertyKeyConst.RAM_ROLE_NAME, "StoreServiceRole");
ConfigService configService = NacosFactory.createConfigService(properties);

经过如上配置，Nacos 客户端在获取配置时，云服务器会扮演指定的 RAM 角色，阿里云临时安全令牌（Security Token Service，STS）来访问 MSE Nacos 实例。

如果攻击者获取代码，也无法在其他机器上运行，因为攻击者的机器没有扮演 RAM 角色的权限。

如果攻击者获取扮演之后的认证信息，由于 STS 失效较短（默认是1小时），攻击者拿到后很快就失效，有效减少了攻击面。

如果需要撤销授权，只需要在阿里云控制台上就可以操作，不需要重新发布应用。

相比于 AK/SK 方式的认证鉴权，ECS 关联角色的认证鉴权更可控、更安全，所以推荐使用这种认证鉴权方式。

配置控制台场景的认证和鉴权

---

开源版本的 Nacos

开源版本的 Nacos 控制台，在登录的时候，会通过控制台的 login 接口，获取临时的 accessToken，然后后续的操作，都是以 accessToken 来做认证鉴权。

比如前文提到的 readonly-user 用户，登录后，就只能看到 public 命名空间下的配置信息，无法修改、无法查看其他命名空间下的配置信息。

另外，如果需要创建命名空间、删除命名空间，则只能管理员登录才可以。

开源版本 Nacos 的认证鉴权，可以参考该文档：https://nacos.io/zh-cn/docs/auth.html。

阿里云 MSE

阿里云 MSE 由于是对企业提供服务，所以在权限的划分上会更加精细。

资源分为实例级别（acs:mse:*:*:instance/${instanceId}）和命名空间级别（acs:mse:*:*:instance/${instanceId}/${namespaceId}）。

对资源的操作也更加精细，比如：

Action	说明
CreateEngineNamespace	创建命名空间
DeleteEngineNamespace	删除命名空间
mse:Get*,mse:List*,mse:Query*	读取配置（Nacos 客户端和控制台）
mse:*	所有权限，包括修改、删除配置
mse:QueryNacosConfig	客户端读取配置
mse:UpdateNacosConfig	客户端修改配置

比如，只允许读取一个命名空间下的配置，不允许修改。那权限策略就可以写：

{
  "Action": [
    "mse:Get*",
    "mse:List*",
    "mse:Query*"
  ],
  "Resource": [
    "acs:mse:*:*:instance/${instanceId}/${namespaceId}"
  ],
  "Effect": "Allow"
}

服务器之间的认证

---

Nacos 服务器之间需要同步一些信息，这时也需要认证对方身份，以确认对方真的是 Nacos-server，而不是伪装的。

在 1.4.1 之前，是通过 User-Agent 这个 header 来认证的，这种原始的认证方式，很容易被伪造。本文开头提到的，1月份 Nacos 爆出的漏洞就是这个原因。

所以 1.4.1 及之后的版本，认证的 header 以及对应的值可以自己配置。在 application.properties 中，修改如下值即可：

# 不使用User-Agent来认证
nacos.core.auth.enable.userAgentAuthWhite=false
# 认证header的key
nacos.core.auth.server.identity=Authorization
# 认证header的value
nacos.core.auth.server.identity.value=secret

这样，只有发送了 header Authorization: secret 的请求，才能确认对方是服务端，才能同步集群信息；否则就拒绝同步。

由于 Nacos-server 需要全部权限才能同步配置数据，所以对于 Nacos-server 之间，则不需要做鉴权。

这样，就能让服务器之间的通信也能做到安全可信了。

阿里云 MSE 上购买的 Nacos 实例，也已经将上述方案反向移植到了 1.2 版本上，也不会有对应的安全问题。

持久化层的安全

---

Nacos 的配置信息，都是存储在持久化层的。比如 Nacos 默认的持久化层是 MySQL。

为了防止通过 git 或者其他方式将 MySQL 的用户名和密码泄漏出去，我们需要定时修改 MySQL 的用户名和密码。

通常的做法是使用两个数据库用户，比如 UserA 和 UserB。如果要更新密码，则按照如下方式操作：

• 将 Nacos server 访问数据库的用户从 UserA 切换到 UserB。
• 更新 UserA 的密码。
• 将 Nacos server 访问数据库的用户从 UserB 切换回UserA。
• 更新 UserB 的密码。

作为阿里云产品，MSE 都有定时修改数据库用户名密码的策略，所以如果您购买了 MSE 实例，则不需要担心此问题。

配置安全最佳实践

---

捋了一遍 Nacos 配置安全的关键点，那么怎么才能保证配置安全呢。只需要做到如下最佳实践就可以了：

1、定期修改密码和 ak/sk

在使用 Nacos 用户名密码（或者 AK/SK）认证的情况下（比如使用开源 Nacos 认证方式），如果恶意用户拿到了 Nacos 的用户名和密码（或者 AK/SK），那么他就有可能拿到应用的配置。但如果定期修改了密码或者 AK/SK 的话，就能有效限制配置泄漏的时间段，减少攻击面。

2、使用 ECS 角色（推荐用法）

当然，在上面的解决方案中，还是会有 Nacos 用户名密码或者 AK/SK 在配置中的，而且这些信息的也有可能泄漏，泄漏后的修改也需要重新发布才可以。所以推荐使用阿里云的 ECS 角色，所有的权限管理都是在阿里云控制台上完成。

3、轮转 Nacos 内部认证的 key

前文有提到 Nacos 服务器之间的认证是通过 nacos.core.auth.server.identity 来完成的，但如果恶意用户入侵，也会导致泄漏，从而导致配置泄漏。

所以对于自建 Nacos，需要定期更换 nacos.core.auth.server.identity.value，确保恶意用户无法伪装为 Nacos Server 来获取、修改配置。

当然，如果您使用的是 MSE 托管的 Nacos 实例的话，MSE 会自动轮转，您可以不用担心这一点。

4、轮转持久化层的用户名和密码

为了防止配置从持久化层泄漏出去，所以需要定时修改持久化层的认证信息。通常 Nacos 的持久化层都是 DB，所以需要定时修改数据库的用户名和密码。

对于 MSE 用户，则不需要做任何操作，MSE 内部会定时修改数据库的用户名和密码。

5、设计安全预案并定时执行

有了如上重重保险，理论上万无一失，但是因为人的操作总有失误，所以还是需要指定安全预案：

• 定时检查配置的监听列表，确认没有未授权的机器。
• AK/SK 泄漏时，该如何更新 AK/SK，如何撤销泄漏的 AK/SK。
• 对于自建 Nacos，服务器被攻破后，如何修改 nacos.core.auth.server.identity.value 的方案。

总结

---

开源的 Nacos 在配置管理、权限管理上，能基本满足中小企业需求。

而对于中大型企业，阿里云产品 MSE 支持更加精细、更加灵活的权限配置、安全管理，也能利用和其他阿里云产品一起做到更加安全的配置能力。

当然，不论是自建 Nacos 还是使用阿里云 MSE，都需要关注上述提到的安全点，防止配置信息泄漏，造成业务损失。最后提到的配置安全最佳实践，也能能保证配置泄漏后，有能力及时修复，做到防患未然。

招贤纳士

---

我们 Dubbo /  Spring Cloud 商业化团队正在招人。除了 EDAS，我们还有 ARMS  (应用实时监控服务)、MSE（微服务引擎）、SAE（Serverless  应用引擎）等独立产品。我们在忙什么？用心打磨这些产品，就是我们的工作。团队的目标是将阿里巴巴在服务治理上的最佳实践通过产品化的形式输出给阿里云上的企业客户，帮助客户实现业务永远在线。

简历投递方式：https://job.alibaba.com/zhaopin/position_detail.htm?positionId=98290

﹀

﹀

﹀

点个在看，让更多人看见