Apache RocketMQ ACL 2.0 全新升级

阿里云云栖号

于 2024-05-11 15:07:26 发布

阅读量1.8k

点赞数 10

分类专栏：云栖号技术分享文章标签： apache rocketmq 云原生云计算阿里云

本文链接：https://blog.csdn.net/yunqiinsight/article/details/138716497

版权

引言

RocketMQ 作为一款流行的分布式消息中间件，被广泛应用于各种大型分布式系统和微服务中，承担着异步通信、系统解耦、削峰填谷和消息通知等重要的角色。随着技术的演进和业务规模的扩大，安全相关的挑战日益突出，消息系统的访问控制也变得尤为重要。然而，RocketMQ 现有的 ACL 1.0 版本已经无法满足未来的发展。因此，我们推出了 RocketMQ ACL 2.0 升级版，进一步提升 RocketMQ 数据的安全性。本文将介绍 RocketMQ ACL 2.0 的新特性、工作原理，以及相关的配置和实践。

升级的背景

ACL 1.0 痛点问题

RocketMQ ACL 1.0 的认证和授权流程如上图所示，在使用过程中，存在着以下痛点问题：

绕过访问控制的 IP 白名单：在标准安全实践中，IP 白名单通常用于限制客户端只能从特定 IP 或 IP 段访问资源。然而，ACL 1.0 中，IP 白名单被异常用于绕过鉴权验证的手段，偏离了标准实践中的安全意图。这种设计上的偏差可能造成潜在的安全隐患，特别是在公网场景中，多个客户端共享同一个 IP 的情况下，会导致未授权的 IP 地址绕过正常的访问控制检查对集群中的数据进行访问。

缺乏管控 API 精细化控制：RocketMQ 提供了 130 多个管控 API，支持了集群配置，Topic、Group 的元数据管理，以及消息查询、位点重置等操作。这些操作涉及到敏感数据的处理，以及影响系统的稳定性。因此，根据用户不同角色或职责，精确定义可访问的 API 和数据范围变得至关重要。然而，ACL 1.0 仅对其中 9 个 API 进行了支持，包括 Topic、Group 元数据，以及Broker配置，剩下的 API 有可能被攻击者利用，对系统进行攻击，窃取敏感的数据。此外，要实施对这么多的管控 API 进行访问控制，现有的设计会导致大量的编码工作，并且在新增 API 时也增加了遗漏的风险。

缺少集群组件间访问控制：在 RocketMQ 架构中，涵盖了 NameServer、Broker 主从节点、Proxy 等多个关键组件。目前，这些组件之间的互相访问缺失了关键的的权限验证机制。因此，一但旦在集群外自行搭建 Broker 从节点或 Proxy 组件，便可以绕过现有的安全机制，访问并获取集群内的敏感数据，这无疑给系统的数据安全和集群的稳定性造成巨大的威胁。

特性与原理

ACL 2.0 新特性

RocketMQ ACL 2.0 针对 ACL 1.0 中的问题进行了解决，同时还带来了六个主要的新特性，具体如下：

精细的API资源权限定义：ACL 2.0 对 RocketMQ 系统中所有的资源都进行了定义，包括集群、命名空间、主题、消费者组，以实现对所有类型的资源进行独立的访问控制。此外，它将所有的 API 都纳入权限控制范畴，覆盖了包括消息收发、集群管理、元数据等各项操作，确保所有资源的任何操作都施加了严格的权限控制。

授权资源的多种匹配模式：在资源众多的集群环境中，为每个资源进行逐一授权会带来繁复的配置过程和管理负担。因此，ACL 2.0 引入了三种灵活的匹配模式：完全匹配、前缀匹配，以及通配符匹配。这些模式可以让用户根据资源的命名规范和结构特点，快速地进行统一的设定，简化权限的管理操作，提升配置的效率。

支持集群组件间访问控制：由于将所有资源类型和API操作都纳入了访问控制体系，集群内部组件之间的连接和访问也受到了权限控制，包括 Broker 主从之间的 Leader 选举、数据复制的过程，以及 Proxy 到 Broker 的数据访问等环节，这可以有效地避免潜在的数据泄露问题和对系统稳定性的风险，加强了整个集群的安全性和可靠性。

用户认证和权限校验分离：通过对认证和授权这两个关键模块进行解耦，系统可以提供类似“只认证不鉴权”等方式的灵活选择，以适应各种不同场景的需求。此外，两个组件可以分别演进、独立发展，从而诞生出多样的认证方式和先进的鉴权方法。

安全性和性能之间的平衡：当启用 ACL 后，客户端的每次请求都必须会经过完整的认证和授权流程。这确保了系统的安全性，但同时也引入了性能上的开销。在 ACL 2.0 中，提供了无状态认证授权策略和有状态认证授权策略，来分别满足对安全有极致要求，以及安全可控但性能优先这两种不同的安全和性能需求。

灵活可扩展的插件化机制：当前市场上，认证方式存在多种实现，授权方式也有不同场景的定制需求。因此，ACL 2.0 设计了一套插件化的框架，在不同层面上进行接口的定义和抽象，以支持未来对认证和授权进行扩展，满足用户根据自身业务需求定制和实现相应的解决方案。

访问控制模型

基于角色的访问控制（RBAC）和基于属性的访问控制（ABAC）是访问控制体系中两种主要的方法。RocketMQ ACL 2.0 将这两种方法进行了融合，打造出了一套更加灵活和强大的访问控制系统。

RBAC 是基于角色的访问控制模型，通过角色进行权限的分配。RocketMQ ACL 2.0 将用户角色划分为超级用户（Super）和普通用户（Normal），超级用户具有最高级别的权限，能够无需授权即可访问资源，这简化了集群初始化及日常运维过程中的权限依赖问题。而普通用户在访问资源之前，需要被赋予相应的权限，适用于业务场景中，对资源进行按需访问。

ABAC 是基于属性的访问控制模型，通过用户、资源、环境、操作等多维属性来表达访问控制策略。RocketMQ ACL 2.0 为普通用户提供了这种灵活的访问控制机制。帮助管理员根据业务需求、用户职责等因素，对资源进行更加精细的访问控制。

在安全体系中，认证和授权分别扮演着不同的角色，RocetMQ ACL 2.0 将认证和授权进行了模块分离。这可以确保两个组件各司其职，降低系统的复杂度。认证服务致力于验证用户身份的合法性，而授权服务则专注于管理用户权限和访问控制。这样的划分不仅可以让代码更易于管理、维护和扩展，也为用户提供了使用上的灵活性。根据需求，用户可以选择单独启用认证或授权服务，也可以选择同时启用两者。这使得 RocketMQ ACL 既可以满足简单场景的快速部署，也能够适应复杂环境下对安全性的严格要求。