乐趣区

关于阿里云:Nacos配置安全最佳实践

jiezi

简介： 本文探讨了自建 Nacos 和阿里云 MSE 的配置平安原理。并提出配置平安最佳实际。

作者：鲁严波

前言

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

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）获取配置

可能的透露点如下：

认证

鉴权

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。如果要更新明码，则依照如下形式操作：

  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 的话，就能无效限度配置透露的时间段，缩小攻击面。

  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，都须要关注上述提到的平安点，避免配置信息透露，造成业务损失。最初提到的配置平安最佳实际，也能能保障配置透露后，有能力及时修复，做到防患未然。
原文链接
本文为阿里云原创内容，未经容许不得转载。

退出移动版