作者：鲁严波

前言

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

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

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

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

Nacos配置架构

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

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

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

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

可能的泄漏点如下：

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客户端获取配置时，需要设置上对应的用户名和密码，才能获取配置：

StringserverAddr="{serverAddr}";
Propertiesproperties=newProperties();
properties.put("serverAddr", serverAddr);
properties.put("username","nacos-readonly");
properties.put("password","nacos");
ConfigServiceconfigService=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就可以了：

StringserverAddr="{serverAddr}";
Propertiesproperties=newProperties();
properties.put("serverAddr", serverAddr);
properties.put(PropertyKeyConst.ACCESS_KEY, "${accessKey}");
properties.put(PropertyKeyConst.SECRET_KEY, "${secret}");
ConfigServiceconfigService=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角色即可：

StringserverAddr="{serverAddr}";
Propertiesproperties=newProperties();
properties.put("serverAddr", serverAddr);
properties.put(PropertyKeyConst.RAM_ROLE_NAME, "StoreServiceRole");
ConfigServiceconfigService=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}）。

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

mse:Get*,mse:List*,mse:Query*

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。如果要更新密码，则按照如下方式操作：

1. 将Nacos server访问数据库的用户从UserA切换到UserB
2. 更新UserA的密码
3. 将Nacos server访问数据库的用户从UserB切换回UserA
4. 更新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

扫码了解更多技术干货和客户案例：