monedula-acl-rbac-converter

配套文章： 从 Kafka ACL 到 Confluent RBAC：借助一款全新开源工具实现安全的迁移路径 讲解了为什么 ACL 到 RBAC 的迁移比看上去更难，以及分步的工作流程。

为什么

在现有的 Kafka 集群上采用 Confluent RBAC，意味着要把每一条原生 ACL 翻译成等效的角色绑定——而这两种模型并不是一一对应的。手工去做既慢、又容易出现细微的错误，事后也难以证明其正确性。

monedula-acl-rbac-converter 让这一迁移变得机械化、可复查。它能从 ACL 所在的任何地方读取——一个运行中的集群、导出的 kafka-acls.sh --list 转储、JSON/YAML/CSV、Strimzi KafkaUser 或 Confluent for Kubernetes 清单、运行中的 Kubernetes 集群，或是一个写满 kafka-acls --add 命令的旧建置脚本——并生成一份 Confluent RBAC 角色绑定计划，每一步都可审计。

工作原理

生产环境的工作流程是显式的、分步进行的，因此每个阶段都会产出可供你复查、版本管理或附加到变更请求中的产物：

extract  ->  plan  ->  apply (dry-run)  ->  apply  ->  verify  ->  delete-acls

根据你希望这个工具触及多少内容，支持两种运行模式：

• 直连（MDS）——将角色绑定直接应用到 Confluent 的 Metadata Service。apply 步骤是幂等的：已存在的绑定会被跳过。
• 仅产物——生成 Confluent CLI 脚本、Confluent for Kubernetes 清单或 mds-curl 命令，交由你自己的 GitOps / 变更管控流水线去应用，因此没有流水线运行就不会有任何改动。

安全是核心：计划会附带校验和，apply 之后会验证有效访问权限（新的绑定确实授予了旧 ACL 所赋予的权限），而删除源 ACL 则是基于脚本的——工具会生成 delete-acls.sh 以及一个 rollback.sh，由人来慎重地复查并运行清理。

配置

转换通过三个可选的 YAML 文件进行调整：scopes.yaml（绑定所针对的 Confluent 集群 ID）、rules.yaml（自定义映射覆盖）和 principals.yaml（主体重映射）。DENY 类 ACL 没有对应的 RBAC 语义，因此不会被悄悄转换——它们会被单独报告并处理。