---
title: "monedula-acl-rbac-converter"
repo: https://github.com/monedula-dev/monedula-acl-rbac-converter
language: Go
license: AGPL-3.0
status: active
maintainers: ["grzegorz", "michal"]
---> **配套文章：** [从 Kafka ACL 到 Confluent RBAC：借助一款全新开源工具实现安全的迁移路径](/blog/kafka-acls-confluent-rbac-migration-monedula-acl-rbac-converter/) 讲解了为什么 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 角色绑定计划，每一步都可审计。

## 工作原理

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

```text
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 语义，因此不会被悄悄转换——它们会被单独报告并处理。