Nacos 配置安全最佳实践
前言
配置管理作为软件开发中重要的一环，肩负着连接代码和环境的职责，能很好的分离开发人员和维护人员的关注点。
Nacos 的配置管理功能就很好地满足了云原生应用对于配置管理的需求：既能做到配置和代码分离，也能做到配置的动态修改。
在 1 月份，Nacos 出了一个安全漏洞，外部用户能够伪装为Nacos-server来获取/修改配置。确认问题后，Nacos 火速修复了漏洞，而阿里云的微服务引擎（MSE）也已在 1 月末将修复方案反向移植到 MSE 上的 Nacos 实例上。
在本文中，我们将会从全局视角入手，讨论如何才能保证 Nacos 配置的安全性（security），即如何保证配置信息不被恶意用户获取或者泄漏。
Nacos 配置架构
Nacos 配置部分的整体架构如下：
对于上图中的每一条链路，都需要考虑有没有两个基本的安全动作：认证（Identification）和鉴权（Authentication）
从上图可以看到，配置信息可能的泄漏通道有：
通过 Nacos-client 获取配置
通过控制台获取配置
通过服务器之间的通信协议获取配置
可能的泄漏点如下：
下面我们分情况讨论下：
Nacos 客户端场景的认证和鉴权
在 Nacos 客户端尝试从服务端获取配置时，服务端需要确认客户端的身份，并确认该身份有权限获取配置。
开源版本的 Nacos
在默认的 Nacos server 配置中，不会对客户端鉴权，即任何能访问 Nacos server 的用户，都可以直接获取 Nacos 中存储的配置。比如一个黑客攻进了企业内网，就能获取所有的业务配置，这样肯定会有安全隐患。
所以需要先开启 Nacos server 的鉴权。在 Nacos server 上修改application.properties中的nacos.core.auth.enabled值为 true 即可：
经过如上设置后，Nacos 客户端获取配置时，需要设置上对应的用户名和密码，才能获取配置：
上面讲了如何认证用户，即如何确定现在是哪一个用户在访问，但还需要识别用户的权限，当用户访问没有权限获取对应配置的时候，比如库存服务尝试获取支付服务的配置时，就会失败。
我们可以在开源的 Nacos 控制台上创建用户、设置权限。步骤如下：
首先，访问 Nacos 控制台（本地环境是 localhost:8848/nacos ）并登录，在权限控制->用户列表页面，添加用户：
在权限控制->角色管理页面，绑定用户和角色：
给对应角色添加权限，在权限控制->权限管理页面，添加权限。比如只能读取 public namespace 下的配置项：
经过如上配置后，readonly-user 就只能访问 public 命名空间下的配置了。
阿里云 MSE-AK/SK
对于小团队，用用户名和密码来做认证鉴权是足够的。但对于中大型团队，密码的定期更换、人员的频繁变动等，都会导致用户名和密码频繁变动。
这时，使用用户名和密码认证鉴权就需要频繁修改并发布应用。为了解决这个问题，Nacos 也支持基于 ak/sk 的认证方案。
以阿里云 MSE 为例，阿里云用户已经普遍使用了阿里云访问控制服务（RAM）作为权限系统，如果 MSE 和开源一样，使用用户名和密码实现认证和鉴权的话，那么用户就需要在 RAM 和 MSE Nacos 两个地方配置权限。这样既不方便用户权限的统一管理、审查，也给用户带来了不一致的体验。
所以 MSE（微服务引擎）提供了基于 ak/sk 的认证方式，操作示例如下：
首先，在 MSE 上申请一个 Nacos 实例（并记下实例 id），然后在实例详情->参数设置界面，将 ConfigAuthEnabled（配置鉴权）参数设置为 true，这样匿名用户就无法获取配置：
然后就可以在阿里云 RAM 系统上配置相关权限。RAM 子账号的权限系统可以简单表示如下：
第一步，创建 RAM 权限策略如下：
图中，mse:Get*、mse:List*、mse:Query*表示能读取配置，mse:*表示所有权限，包括修改权限。
Resource 中的acs:mse:::instance/${instanceId}表示授权到实例级别，acs:mse:::instance/${instanceId}/${namespaceId}表示授权到命名空间级别。
第二步，创建用户并赋予权限
填写用户名称：
然后获取到用户的 ak/sk：
给这个用户对应的权限：
最后，只需要在代码中添加 ak/sk 就可以了：
经过如上配置，客户端在访问 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 角色即可：
经过如上配置，Nacos 客户端在获取配置时，云服务器会扮演指定的 RAM 角色，阿里云临时安全令牌（Security Token Service，STS）来访问 MSE Nacos 实例。
如果攻击者获取代码，也无法在其他机器上运行，因为攻击者的机器没有扮演 RAM 角色的权限。
如果攻击者获取扮演之后的认证信息，由于 STS 失效较短（默认是 1 小时），攻击者拿到后很快就失效，有效减少了攻击面。
如果需要撤销授权，只需要在阿里云控制台上就可以操作，不需要重新发布应用。
相比于 AK/SK 方式的认证鉴权，ECS 关联角色的认证鉴权更可控、更安全，所以推荐使用这种认证鉴权方式。
配置控制台场景的认证和鉴权
阿里云 MSE 由于是对企业提供服务，所以在权限的划分上会更加精细。
资源的分为实例级别（acs:mse:*:*:instance/${instanceId}）和命名空间级别（acs:mse:*:*:instance/${instanceId}/${namespaceId}）。
对资源的操作也更加精细，比如：
比如，只允许读取一个命名空间下的配置，不允许修改。那权限策略就可以写：
服务器之间的认证
Nacos 服务器之间需要同步一些信息，这时也需要认证对方身份，以确认对方真的是 Nacos-server，而不是伪装的。
在 1.4.1 之前，是通过User-Agent这个 header 来认证的，这种原始的认证方式，很容易被伪造。本文开头提到的，1 月份 Nacos 爆出的漏洞就是这个原因。
所以 1.4.1 及之后的版本，认证的 header 以及对应的值可以自己配置。在application.properties中，修改如下值即可：
这样，只有发送了 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 实例，则不需要担心此问题。
配置安全最佳实践
定期修改密码和 ak/sk
在使用 Nacos 用户名密码（或者 ak/sk）认证的情况下（比如使用开源 Nacos 认证方式），如果恶意用户拿到了 Nacos 的用户名和密码（或者 ak/sk），那么他就有可能拿到应用的配置。但如果定期修改了密码或者 ak/sk 的话，就能有效限制配置泄漏的时间段，减少攻击面。
使用 ECS 角色（推荐用法）
当然，在上面的解决方案中，还是会有 Nacos 用户名密码或者 ak/sk 在配置中的，而且这些信息的也有可能泄漏，泄漏后的修改也需要重新发布才可以。所以推荐使用阿里云的 ecs 角色，所有的权限管理都是在阿里云控制台上完成。
轮转 Nacos 内部认证的 key
前文有提到 Nacos 服务器之间的认证是通过 nacos.core.auth.server.identity 来完成的，但如果恶意用户入侵，也会导致泄漏，从而导致配置泄漏。
所以对于自建 Nacos，需要定期更换 nacos.core.auth.server.identity.value，确保恶意用户无法伪装为 Nacos server 来获取、修改配置。
当然，如果您使用的是 MSE 托管的 Nacos 实例的话，MSE 会自动轮转，您可以不用担心这一点。
轮转持久化层的用户名和密码
为了防止配置从持久化层泄漏出去，所以需要定时修改持久化层的认证信息。通常 Nacos 的持久化层都是 DB，所以需要定时修改数据库的用户名和密码。
对于 MSE 用户，则不需要做任何操作，MSE 内部会定时修改数据库的用户名和密码。
设计安全预案并定时执行
有了如上重重保险，理论上万无一失，但是因为人的操作总有失误，所以还是需要指定安全预案：
定时检查配置的监听列表，确认没有未授权的机器在获取配置
ak/sk 泄漏时，该如何更新 ak/sk，如何撤销泄漏的 ak/sk
自建 Nacos，服务器被攻破后，如何修改
nacos.core.auth.server.identity.value的方案
总结
开源的 Nacos 在配置管理、权限管理上，能基本满足中小企业需求。
而对于中大型企业，阿里云产品 MSE 支持更加精细、更加灵活的权限配置、安全管理，也能利用和其他阿里云产品一起做到更加安全的配置能力。
当然，不论是自建 Nacos 还是使用阿里云 MSE，都需要关注上述提到的安全点，防止配置信息泄漏，造成业务损失。最后提到的配置安全最佳实践，也能能保证配置泄漏后，有能力及时修复，做到防患未然。
版权声明: 本文为 InfoQ 作者【Robert Lu】的原创文章。
原文链接:【http://xie.infoq.cn/article/ec43bd9f89c3fb93e97729242】。文章转载请联系作者。
还未添加个人签名 2015.04.06 加入
还未添加个人简介
评论