前言

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

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的keynacos.core.auth.server.identity=Authorization# 认证header的valuenacos.core.auth.server.identity.value=secret

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

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

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

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