前言

Nacos 配置架构

• 通过 Nacos-client 获取配置。
• 通过控制台获取配置。
• 通过服务器之间的通信协议获取配置。
• 直接访问持久化层（比如 DB）获取配置。
  

Nacos 客户端场景的认证和鉴权

开源版本的 Nacos

 
   
   
 

  
    
    
  
 
   
 
  
  
    
    
  
nacos.core.auth.enabled=true
 
   
   
 
 
   
   
 

  
    
    
  

 
   
   
 

 
   
   
 

  
    
    
  
 
   
 
   
 
   
 
   
 
   
 
   
 
  
  
    
    
  
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);
 
   
   
 

阿里云 MSE-AK/SK

• 第一步：创建 RAM 权限策略如下：

• 第二步：创建用户并赋予权限：

• 最后，只需要在代码中添加 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- 基于 ECS 的 Ram 角色认证

• 第一步，创建 MSE Nacos 实例，并创建对应的权限策略（上文有说明，此处不赘述）。

• 第二步，创建 RAM 角色并授权。

• 第三步，将该角色和 ECS 关联：

• 最后一步，在代码中 指定 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:Get*,mse:List*,mse:Query*

mse:*

mse:QueryNacosConfig

mse:UpdateNacosConfig

比如，只允许读取一个命名空间下的配置，不允许修改。那权限策略就可以写：

 
   
   
 

  
    
    
  
 
   
 
   
 
   
 
   
 
   
 
   
 
   
 
   
 
   
 
   
 
   
 
  
  
    
    
  
{ "Action": [ "mse:Get*", "mse:List*", "mse:Query*" ], "Resource": [ "acs:mse:*:*:instance/${instanceId}/${namespaceId}" ], "Effect": "Allow"}
 
   
   
 
 
   
   
 

  
    
    
  
  
    
    
  

 
   
   
 
 
   
   
 

  
    
    
  

 
   
   
 

服务器之间的认证

Nacos 服务器之间需要同步一些信息，这时也需要认证对方身份，以确认对方真的是 Nacos-server，而不是伪装的。

 
   
   
 

  
    
    
  
 
   
 
   
 
   
 
   
 
   
 
   
 
  
  
    
    
  
# 不使用User-Agent来认证nacos.core.auth.enable.userAgentAuthWhite=false# 认证header的keynacos.core.auth.server.identity=Authorization# 认证header的valuenacos.core.auth.server.identity.value=secret
 
   
   
 
 
   
   
 

  
    
    
  
  
    
    
  

 
   
   
 

持久化层的安全

• 将 Nacos server 访问数据库的用户从 UserA 切换到 UserB。
• 更新 UserA 的密码。
• 将 Nacos server 访问数据库的用户从 UserB 切换回UserA。
• 更新 UserB 的密码。

配置安全最佳实践

捋了一遍 Nacos 配置安全的关键点，那么怎么才能保证配置安全呢。只需要做到如下最佳实践就可以了：

• 定时检查配置的监听列表，确认没有未授权的机器。
• AK/SK 泄漏时，该如何更新 AK/SK，如何撤销泄漏的 AK/SK。
• 对于自建 Nacos，服务器被攻破后，如何修改 nacos.core.auth.server.identity.value 的方案。

总结

而对于中大型企业，阿里云产品 MSE 支持更加精细、更加灵活的权限配置、安全管理，也能利用和其他阿里云产品一起做到更加安全的配置能力。

招贤纳士

我们 Dubbo /  Spring Cloud 商业化团队正在招人。除了 EDAS，我们还有 ARMS  (应用实时监控服务)、MSE（微服务引擎）、SAE（Serverless  应用引擎）等独立产品。我们在忙什么？用心打磨这些产品，就是我们的工作。团队的目标是将阿里巴巴在服务治理上的最佳实践通过产品化的形式输出给阿里云上的企业客户，帮助客户实现业务永远在线。