--- title: "Von Kafka-ACLs zu Confluent RBAC: Ein sicherer Migrationspfad mit einem neuen Open-Source-Tool" date: 2026-06-17T00:00:00.000Z author: "michal" excerpt: "Der Wechsel eines bestehenden Kafka-Bestands von ACLs zu Confluent RBAC ist eine Übung im Risikomanagement, keine Syntaxkonvertierung. Hier ist ein sicherer, prüfbarer, wiederholbarer Migrations-Workflow — und das Tool, das wir dafür gebaut haben." --- Wenn wir mit Banken und großen Unternehmen arbeiten, ist Kafka selten ein Greenfield-Thema. Häufiger läuft Kafka bereits seit Jahren. Teams sind davon abhängig, kritische Daten fließen hindurch, und die Plattform hat eine lange Historie aus operativen Entscheidungen, Namenskonventionen, Service-Accounts, Topic-Mustern und Zugriffsregeln angesammelt. Wenn eine Organisation sich entscheidet, auf Confluent Platform umzusteigen, ist Kafka nicht mehr nur ein Messaging-System. Es ist Teil des Produktions-Rückgrats. Dieser Kontext ist wichtig, denn Migrationen in solchen Umgebungen sind nicht nur technische Projekte. Sie sind Übungen im Risikomanagement. In der ersten Phase einer Confluent-Migration ist der sicherste Ansatz meist, so wenig wie möglich zu ändern. Das Ziel besteht darin, das Plattformfundament zu verschieben, es zu stabilisieren und erst danach größere Verbesserungen einzuführen. Authentifizierung und Autorisierung sind Teil dieser Geschichte. Bestehende Kafka-Installationen setzen oft auf [Apache-Kafka-ACLs](https://kafka.apache.org/documentation/#security_authz), weil ACLs das eingebaute Autorisierungsmodell sind, das in Open-Source-Kafka verfügbar ist. Confluent Platform bietet jedoch auch [RBAC: rollenbasierte Zugriffskontrolle](https://docs.confluent.io/platform/current/security/authorization/rbac/overview.html). RBAC ist auf organisatorischer Ebene meist leichter nachvollziehbar, passt besser zur Plattform-Governance und integriert sich natürlich mit anderen Confluent-Komponenten wie Metadata Service, Control Center und [Confluent for Kubernetes](https://docs.confluent.io/operator/current/overview.html). Damit stellt sich die Frage: Wie wechselt man von einem bestehenden ACL-basierten Kafka-Bestand zu Confluent RBAC, ohne die Zugriffskontrolle in eine hochriskante manuelle Migration zu verwandeln? Genau deshalb haben wir `monedula-acl-rbac-converter` gebaut. ## Warum die ACL-zu-RBAC-Migration schwieriger ist, als sie aussieht Ein kleiner Kafka-Cluster mit einer Handvoll Topics und Benutzern kann manuell migriert werden. Man inspiziert die ACLs, entscheidet sich für die äquivalenten RBAC-Rollen, erstellt Bindings, verifiziert den Zugriff und entfernt die alten ACLs. Aber so sehen die meisten ausgereiften Unternehmensumgebungen nicht aus. In realen Deployments findet man möglicherweise Hunderte oder Tausende von ACL-Regeln. Einige wurden von Plattform-Teams erstellt. Einige von Anwendungsteams. Einige stammen aus Automatisierung. Einige sind alt, werden aber noch genutzt. Einige verwenden präfixbasierte Topic-Muster. Einige verweisen auf Service-Benutzer, die seitdem umbenannt wurden. Einige wurden aus Skripten exportiert, die seit Jahren niemand mehr angefasst hat. Eine manuelle Migration hat in diesem Kontext mehrere Probleme: - sie ist langsam, - sie ist fehleranfällig, - sie ist schwer zu überprüfen, - sie ist schwer zu wiederholen, - sie ist schwer zu auditieren, - und sie wird gefährlich, wenn das Aufräumen beginnt. Das Erstellen neuer RBAC-Bindings ist nur die Hälfte der Migration. Der heiklere Teil besteht darin, nachzuweisen, dass die neuen Bindings denselben effektiven Zugriff bieten wie die alten ACLs, und erst dann die ursprünglichen ACLs zu entfernen. Deshalb wollten wir kein Tool, das einfach "eine Datei übersetzt". Wir wollten einen Migrations-Workflow. ## Was der Converter macht `monedula-acl-rbac-converter` ist ein Kommandozeilen-Tool, das bestehende Kafka-ACLs liest, sie in einen Confluent-RBAC-Rollenbindungsplan umwandelt und Operatoren dabei hilft, die Migration auf kontrollierte, prüfbare Weise durchzuführen. Es kann ACLs aus mehreren realen Quellen lesen, darunter: - ein aktiver Kafka-Cluster, - exportierte `kafka-acls.sh --list`-Ausgaben, - JSON-, YAML- oder CSV-Dumps, - Strimzi-`KafkaUser`-Manifeste, - Confluent-for-Kubernetes-Manifeste, - ein laufender Kubernetes-Cluster, - oder ein Shell-Skript mit `kafka-acls --add ...`-Befehlen. Dieser letzte Fall ist in Brownfield-Umgebungen besonders nützlich. Viele Teams starten nicht von einem sauberen Export. Stattdessen haben sie ein altes Setup-Skript, das die ACLs überhaupt erst erstellt hat. Ein Eingabeskript kann zum Beispiel Befehle wie diese enthalten: ```sh kafka-acls.sh \ --bootstrap-server kafka.example.com:9093 \ --command-config admin.properties \ --add \ --allow-principal User:svc-billing \ --operation Read \ --topic billing.events \ --group billing-consumer kafka-acls.sh \ --bootstrap-server kafka.example.com:9093 \ --command-config admin.properties \ --add \ --allow-principal User:svc-billing \ --operation Describe \ --topic billing.events ``` Der Converter kann diese ACL-Definitionen in eine kanonische `acls.json`-Datei extrahieren. Von dort aus kann er einen überprüften Migrationsplan erzeugen, Skripte oder Manifeste ausgeben, Bindings direkt auf Confluent MDS anwenden, das Ergebnis verifizieren und Cleanup-Skripte für alte ACLs generieren. ## Ein Workflow für hochriskante Änderungen Migrationen der Zugriffskontrolle brauchen Leitplanken. Eine falsche Berechtigung kann Produktions-Workloads lahmlegen. Eine zu breite Berechtigung kann einen Sicherheitsvorfall verursachen. Ein zu früh ausgeführter Cleanup-Schritt kann einen Ausfall verursachen. Aus diesem Grund ist der Produktions-Workflow explizit und schrittbasiert: ```text 1. extract -> kanonischen ACL-Snapshot erstellen 2. plan -> ACLs in einen RBAC-Migrationsplan umwandeln 3. apply dry-run -> MDS-Änderungen vorab ansehen 4. apply -> RBAC-Rollenbindungen erstellen 5. verify -> effektiven Zugriff prüfen 6. wait -> Benutzer den neuen Pfad testen lassen 7. delete-acls -> Löschskript für alte ACLs generieren 8. review + run -> Cleanup manuell ausführen ``` Jeder Schritt erzeugt Artefakte, die inspiziert, überprüft, versioniert oder einem Change-Request beigefügt werden können. Das Tool trennt bewusst Planung von Anwendung, Anwendung von Verifizierung und Verifizierung von Löschung. Das macht die Migration leichter nachvollziehbar und sicherer in der Ausführung in regulierten Umgebungen. ## Beispiel: Migration aus einem ACL-Setup-Skript Nehmen wir an, der Ausgangspunkt ist ein Shell-Skript mit `kafka-acls.sh --add`-Befehlen. ### 1. ACLs extrahieren Extrahieren Sie zunächst die ACLs in eine kanonische JSON-Darstellung: ```sh monedula-acl-rbac extract \ --from script \ --input setup-acls.sh \ --vars vars.yaml \ --out runs/billing-batch-1/acls.json ``` Die optionale `vars.yaml`-Datei ist nützlich, wenn das Skript Variablen enthält. Das Tool rät keine ungelösten Werte. Sind Variablen vorhanden, sollten sie explizit angegeben werden, oder das Skript sollte vor der Migration vorab expandiert werden. In diesem Stadium ist die Ausgabe noch nur ein Snapshot. Es wird kein externer Zustand verändert. ### 2. Einen Migrationsplan erstellen Wandeln Sie als Nächstes die extrahierten ACLs in einen Rollenbindungsplan um: ```sh monedula-acl-rbac plan \ --acls runs/billing-batch-1/acls.json \ --scopes scopes.yaml \ --rules rules.yaml \ --principals principals.yaml \ --out runs/billing-batch-1/plan.json ``` Die `scopes.yaml`-Datei identifiziert die Confluent-Cluster, auf die RBAC-Bindings abzielen sollen. Optionale `rules.yaml`- und `principals.yaml`-Dateien erlauben es Operatoren, die Konvertierung an ihre Umgebung anzupassen, zum Beispiel durch Mapping von Quell-Principals auf das von MDS erwartete Principal-Format. Der Planungsschritt erzeugt außerdem einen Bericht. Dies ist einer der wichtigsten Überprüfungspunkte im Workflow. Er zeigt, was aus jeder Quell-ACL geworden ist, und markiert alles, was nicht abgebildet werden konnte oder nicht automatisch konvertiert werden sollte. ### 3. Den Bericht lesen Bevor irgendetwas angewendet wird, sollten Operatoren den erzeugten Bericht lesen. Hier wird die Migrationsarbeit sichtbar. Statt sich auf eine Black-Box-Konvertierung zu verlassen, kann das Team die erzeugten Bindings überprüfen, nicht abgebildete ACLs untersuchen und entscheiden, ob benutzerdefinierte Mapping-Regeln erforderlich sind. DENY-ACLs verdienen besondere Aufmerksamkeit. Confluent RBAC hat keine äquivalente Deny-Semantik, daher werden DENY-ACLs nicht stillschweigend konvertiert. Sie werden gemeldet und separat behandelt. ### 4. Den Apply-Schritt im Dry-Run ausführen Bevor Sie Rollenbindungen in MDS erstellen, führen Sie einen Dry-Run aus: ```sh monedula-acl-rbac apply \ --plan runs/billing-batch-1/plan.json \ --mds-url https://mds.example.com \ --mds-token-file ~/.confluent/token \ --dry-run ``` Der Dry-Run zeigt eine Vorschau der MDS-Aufrufe, die getätigt würden. Er führt außerdem Lese-Prüfungen durch, sodass bestehende Bindings idempotent übersprungen werden können. Das gibt Operatoren einen weiteren Kontrollpunkt vor der ersten echten Änderung. ### 5. RBAC-Bindings anwenden Sobald die Dry-Run-Ausgabe überprüft wurde, wenden Sie den Plan an: ```sh monedula-acl-rbac apply \ --plan runs/billing-batch-1/plan.json \ --mds-url https://mds.example.com \ --mds-token-file ~/.confluent/token \ --confirm ``` Der Apply-Schritt erstellt RBAC-Bindings in Confluent MDS. Er ist darauf ausgelegt, erneut ausführbar zu sein: Existiert ein Binding bereits, wird es übersprungen. ### 6. Effektiven Zugriff verifizieren Nachdem Sie RBAC-Bindings angewendet haben, verifizieren Sie, dass sie tatsächlich den Zugriff gewähren, der ursprünglich durch die ACLs bereitgestellt wurde: ```sh monedula-acl-rbac verify \ --plan runs/billing-batch-1/plan.json \ --mds-url https://mds.example.com \ --mds-token-file ~/.confluent/token ``` Das ist aussagekräftiger, als nur zu prüfen, ob ein Binding existiert. Das Ziel ist, den effektiven Zugriff für den ursprünglichen Principal, die Operation und die Ressource zu bestätigen. Diese Unterscheidung ist in Unternehmensumgebungen wichtig, in denen Identitätspropagierung, Gruppenzugehörigkeit, LDAP-Integration oder Scope-Diskrepanzen dazu führen können, dass ein Binding existiert, sich aber nicht wie erwartet verhält. ### 7. ACL-Löschskripte generieren Erst nach erfolgreicher Verifizierung und nach einer vom Operator definierten Abkühlphase sollten Quell-ACLs entfernt werden. Das Tool löscht ACLs nicht direkt. Stattdessen generiert es ein Skript, das Operatoren selbst inspizieren und ausführen können: ```sh monedula-acl-rbac delete-acls \ --plan runs/billing-batch-1/plan.json \ --verify runs/billing-batch-1/verify.json \ --bootstrap-server kafka.example.com:9093 \ --command-config admin.properties \ --principal User:svc-billing \ --confirm \ --i-understand-this-is-destructive ``` Zu den erzeugten Artefakten gehören: ```text delete-acls.sh deleted-acls.json rollback.sh ``` Dies ist ein bewusster menschlicher Kontrollpunkt. Der Operator kann das Skript öffnen, jeden `kafka-acls --remove`-Befehl überprüfen, es für jeweils einen Principal ausführen und das Rollback-Skript aufbewahren, bis die Migration stabil ist. ## Unterschiedliche Ausgaben für unterschiedliche Betriebsmodelle Nicht jede Organisation möchte dasselbe Apply-Modell. Einige Teams sind damit einverstanden, direkt auf MDS anzuwenden. Andere benötigen, dass jede Änderung einen Change-Control-Prozess, einen GitOps-Flow oder eine externe CD-Pipeline durchläuft. Der Converter unterstützt diese Szenarien, indem er verschiedene Artefakttypen ausgibt: ```sh # Shell-Skript mit Confluent CLI-Rollenbindungsbefehlen monedula-acl-rbac emit \ --plan runs/billing-batch-1/plan.json \ --format script \ --out-dir emit/ # Confluent for Kubernetes-Manifeste monedula-acl-rbac emit \ --plan runs/billing-batch-1/plan.json \ --format cfk \ --out-dir emit/ # curl-Befehle gegen die MDS REST API monedula-acl-rbac emit \ --plan runs/billing-batch-1/plan.json \ --format mds-curl \ --out-dir emit/ ``` Das macht das Tool sowohl für praktische Migrationsarbeit nützlich als auch für Umgebungen, in denen Infrastrukturänderungen ein separates Genehmigungs- und Deployment-System durchlaufen müssen. ## Gebaut für echtes Migrations-Chaos Wir haben versucht, die Arten von Eingaben und Einschränkungen zu unterstützen, die in tatsächlichen Kafka-Beständen auftauchen, nicht nur saubere Demo-Fälle. Dazu gehören: - Live-Kafka-Extraktion, - Text-Exporte, - strukturierte Dateien, - Kubernetes-native Ressourcen, - bestehende Confluent-for-Kubernetes-Manifeste, - alte Setup-Skripte, - Principal-Remapping, - benutzerdefinierte Konvertierungsregeln, - Dry-Run-Ausführung, - direktes MDS-Apply, - ausgegebene Skripte und Manifeste, - Verifizierung des effektiven Zugriffs, - Generierung von Löschskripten, - Rollback-Artefakte, - und Status-/Diff-Befehle für wiederholbare Migrations-Batches. Das Ergebnis ist ein Tool, das sowohl für Erkundung als auch für produktionsreife Migrationen verwendet werden kann. Für kleine Experimente kann der One-Shot-Befehl `convert` Extraktion, Planung und Skript-Ausgabe in einem einzigen Schritt ausführen: ```sh monedula-acl-rbac convert \ --from yaml \ --input acls.yaml \ --scopes scopes.yaml \ --rules rules.yaml \ --principals principals.yaml \ > bindings.sh ``` Für die Produktion ist die explizite Pipeline der empfohlene Weg, weil sie Audit-Artefakte und Überprüfungspunkte bewahrt. ## Abschließende Gedanken Die Migration von Kafka-ACLs zu Confluent RBAC ist nicht nur ein Problem der Syntaxkonvertierung. Es ist eine kontrollierte Änderung am Autorisierungsmodell einer laufenden Datenplattform. In großen Organisationen, besonders im Bankwesen und in regulierten Branchen, muss diese Änderung überprüfbar, wiederholbar, prüfbar und nach Möglichkeit umkehrbar sein. Wir haben `monedula-acl-rbac-converter` gebaut, weil wir immer wieder dasselbe Muster sahen: Kafka war bereits da, ACLs waren bereits da, und Teams wollten Confluent RBAC einführen, ohne unter Migrationsdruck Hunderte von Regeln manuell zu übersetzen. Das Tool soll den Migrationsprozess nicht verbergen. Es soll ihn sichtbar machen. Extrahieren Sie den aktuellen Zustand. Planen Sie den Zielzustand. Überprüfen Sie den Bericht. Führen Sie die Änderungen im Dry-Run aus. Wenden Sie bewusst an. Verifizieren Sie den effektiven Zugriff. Generieren Sie Cleanup-Skripte. Überprüfen Sie sie. Entfernen Sie dann alte ACLs erst, wenn Sie bereit sind. Das ist die Art von Workflow, die wir uns für Migrationen der Zugriffskontrolle wünschen. Wir haben es gebaut, weil es für uns nützlich ist. Wir hoffen, dass es auch für andere nützlich sein wird. Sie finden [`monedula-acl-rbac-converter` auf GitHub](https://github.com/monedula-dev/monedula-acl-rbac-converter). Wenn Sie einen Bug finden oder einen Verbesserungsvorschlag haben, eröffnen Sie gerne ein Issue.