---
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 に直接適用します。適用ステップは冪等です。既存のバインディングはスキップされます。
- **成果物のみ** — Confluent CLI のスクリプト、Confluent for Kubernetes の
  マニフェスト、または `mds-curl` コマンドを出力し、独自の GitOps／変更管理
  パイプラインで適用します。これにより、パイプラインが実行しない限り何も変更されません。

安全性が肝心です。計画にはチェックサムが付与され、適用後には実効アクセスが
検証され（新しいバインディングが本当に古い ACL と同じものを付与しているか）、
ソース ACL の削除はスクリプトベースです——ツールは `delete-acls.sh` と
`rollback.sh` を生成するため、人間がクリーンアップを慎重にレビューして実行します。

## 設定

変換は三つのオプションの YAML ファイルで調整します。`scopes.yaml`（バインディングの
対象とする Confluent クラスター ID）、`rules.yaml`（カスタムマッピングの
上書き）、`principals.yaml`（プリンシパルの再マッピング）です。DENY ACL には RBAC の
同等物がないため、黙って変換されることはありません——それらはレポートされ、
別途処理されます。