Begleitender Beitrag: Von Kafka-ACLs zu Confluent RBAC: Ein sicherer Migrationspfad mit einem neuen Open-Source-Tool 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:

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.