共计 6376 个字符,预计需要花费 16 分钟才能阅读完成。
简介: 本文探讨了自建 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)
从上图能够看到,配置信息可能的透露形式有:
- 通过 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 的 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。如果要更新明码,则依照如下形式操作:
- 将 Nacos server 拜访数据库的用户从 UserA 切换到 UserB
- 更新 UserA 的明码
- 将 Nacos server 拜访数据库的用户从 UserB 切换回 UserA
- 更新 UserB 的明码
作为阿里云产品,MSE 都有定时批改数据库用户名明码的策略,所以如果您购买了 MSE 实例,则不须要放心此问题。
配置平安最佳实际
捋了一遍 Nacos 配置平安的关键点,那么怎么能力保障配置平安呢。只须要做到如下最佳实际就能够了:
- 定期批改明码和 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,都须要关注上述提到的平安点,避免配置信息透露,造成业务损失。最初提到的配置平安最佳实际,也能能保障配置透露后,有能力及时修复,做到防患未然。
原文链接
本文为阿里云原创内容,未经容许不得转载。