前言

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

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版本上，也不会有对应的平安问题。 # 长久化层的平安 Nacos的配置信息，都是存储在长久化层的。比方Nacos默认的长久化层是MySQL。为了避免通过git或者其余形式将MySQL的用户名和明码透露进来，咱们须要定时批改MySQL的用户名和明码。通常的做法是应用两个数据库用户，比方UserA和UserB。如果要更新明码，则依照如下形式操作： 1. 将Nacos server拜访数据库的用户从UserA切换到UserB2. 更新UserA的明码3. 将Nacos server拜访数据库的用户从UserB切换回UserA4. 更新UserB的明码作为阿里云产品，MSE都有定时批改数据库用户名明码的策略，所以如果您购买了MSE实例，则不须要放心此问题。# 配置平安最佳实际捋了一遍Nacos配置平安的关键点，那么怎么能力保障配置平安呢。只须要做到如下最佳实际就能够了： 1. 定期批改明码和ak/sk在应用Nacos用户名明码（或者ak/sk）认证的状况下（比方应用开源Nacos认证形式），如果歹意用户拿到了Nacos的用户名和明码（或者ak/sk），那么他就有可能拿到利用的配置。但如果定期批改了明码或者ak/sk的话，就能无效限度配置透露的时间段，缩小攻击面。1. 应用ECS角色（举荐用法）当然，在下面的解决方案中，还是会有Nacos用户名明码或者ak/sk在配置中的，而且这些信息的也有可能透露，透露后的批改也须要从新公布才能够。所以举荐应用阿里云的ecs角色，所有的权限治理都是在阿里云管制台上实现。 1. 轮转Nacos外部认证的key前文有提到Nacos服务器之间的认证是通过nacos.core.auth.server.identity来实现的，但如果歹意用户入侵，也会导致透露，从而导致配置透露。所以对于自建Nacos，须要定期更换nacos.core.auth.server.identity.value，确保歹意用户无奈假装为Nacos server来获取、批改配置。当然，如果您应用的是MSE托管的Nacos实例的话，MSE会主动轮转，您能够不必放心这一点。 1. 轮转长久化层的用户名和明码为了避免配置从长久化层透露进来，所以须要定时批改长久化层的认证信息。通常Nacos的长久化层都是DB，所以须要定时批改数据库的用户名和明码。 对于MSE用户，则不须要做任何操作，MSE外部会定时批改数据库的用户名和明码。 1. 设计平安预案并定时执行 有了如上重重保险，实践上十拿九稳，然而因为人的操作总有失误，所以还是须要指定平安预案： * 定时查看配置的监听列表，确认没有未受权的机器在获取配置* ak/sk透露时，该如何更新ak/sk，如何撤销透露的ak/sk* 自建Nacos，服务器被攻破后，如何批改nacos.core.auth.server.identity.value的计划 # 总结开源的Nacos在配置管理、权限治理上，能根本满足中小企业需要。而对于中大型企业，阿里云产品MSE反对更加精密、更加灵便的权限配置、平安治理，也能利用和其余阿里云产品一起做到更加平安的配置能力。当然，不论是自建Nacos还是应用阿里云MSE，都须要关注上述提到的平安点，避免配置信息透露，造成业务损失。最初提到的配置平安最佳实际，也能能保障配置透露后，有能力及时修复，做到防患未然。 *> 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。