関連記事： 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 に直接適用します。適用ステップは冪等です。既存のバインディングはスキップされます。
- 成果物のみ — 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 の
同等物がないため、黙って変換されることはありません——それらはレポートされ、
別途処理されます。