---
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"]
---> **Begleitender Beitrag:** [Von Kafka-ACLs zu Confluent RBAC: Ein sicherer Migrationspfad mit einem neuen Open-Source-Tool](/blog/kafka-acls-confluent-rbac-migration-monedula-acl-rbac-converter/) erklärt, warum die ACL-zu-RBAC-Migration schwieriger ist, als sie aussieht, und den Schritt-für-Schritt-Workflow.

## Warum

Die Einführung von Confluent RBAC auf einem bestehenden Kafka-Cluster bedeutet,
jede native ACL in eine äquivalente Rollenbindung zu übersetzen — und die beiden
Modelle bilden sich nicht eins zu eins ab. Von Hand erledigt ist es langsam,
leicht subtil falsch zu machen und im Nachhinein schwer als korrekt nachzuweisen.

`monedula-acl-rbac-converter` macht diese Migration mechanisch und überprüfbar.
Es liest ACLs aus jeder Quelle, in der sie leben — ein aktiver Cluster, ein
exportierter `kafka-acls.sh --list`-Dump, JSON/YAML/CSV, Strimzi-`KafkaUser`-
oder Confluent-for-Kubernetes-Manifeste, ein laufender Kubernetes-Cluster oder
ein altes Setup-Skript voller `kafka-acls --add`-Befehle — und erzeugt einen
Confluent-RBAC-Rollenbindungsplan, wobei jeder Schritt prüfbar ist.

## Wie es funktioniert

Der Produktions-Workflow ist explizit und schrittbasiert, sodass jede Phase
Artefakte erzeugt, die Sie überprüfen, versionieren oder einem Change-Request
beifügen können:

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

Zwei Betriebsmodelle werden unterstützt, abhängig davon, wie viel das Tool
anfassen soll:

- **Direkt (MDS)** — wenden Sie Rollenbindungen direkt auf Confluents Metadata
  Service an. Der Apply-Schritt ist idempotent: bestehende Bindings werden
  übersprungen.
- **Nur Artefakte** — geben Sie Confluent-CLI-Skripte, Confluent-for-Kubernetes-
  Manifeste oder `mds-curl`-Befehle für Ihre eigene GitOps-/Change-Control-
  Pipeline aus, sodass sich nichts ändert, ohne dass eine Pipeline es ausführt.

Sicherheit ist der Sinn der Sache: Pläne werden mit Prüfsummen versehen, der
effektive Zugriff wird nach dem Apply verifiziert (die neuen Bindings gewähren
wirklich das, was die alten ACLs gewährten), und die Löschung der Quell-ACLs ist
skriptbasiert — das Tool generiert `delete-acls.sh` plus eine `rollback.sh`,
sodass ein Mensch das Aufräumen bewusst überprüft und ausführt.

## Konfigurieren

Die Konvertierung wird mit drei optionalen YAML-Dateien abgestimmt: `scopes.yaml`
(die Confluent-Cluster-IDs, auf die Bindings abzielen), `rules.yaml`
(benutzerdefinierte Mapping-Overrides) und `principals.yaml` (Principal-
Remapping). DENY-ACLs haben kein RBAC-Äquivalent, daher werden sie nicht
stillschweigend konvertiert — sie werden gemeldet und separat behandelt.