Monedula

Diese Seite wurde maschinell aus dem Englischen übersetzt. Original lesen

monedula-acl-rbac-converter v0.10.0, AGPL-3.0

Kafka-ACLs zu RBAC migrieren und Zugriff verifizieren

monedula-acl-rbac-converter liest Ihre Kafka-ACLs, wo immer sie liegen, plant die entsprechenden Confluent-RBAC-Rollenbindungen, wendet sie an und fragt MDS, ob jede ursprüngliche Berechtigung noch gilt. Erst dann schreibt es das Skript, das die alten ACLs löscht.

Go
go install github.com/monedula-dev/monedula-acl-rbac-converter/cmd/monedula-acl-rbac@latest
runs/<timestamp>/plan.json (Auszug)
{
  "schema_version": "1",
  "bindings": [
    {
      "id": "rb-b6fac2ae9aa0",
      "action": "CREATE",
      "principal": "User:svc-analytics",
      "role": "DeveloperRead",
      "scope": { "kafka_cluster": "lkc-demo-1" },
      "resource_patterns": [
        { "resource_type": "Topic", "name": "events.", "pattern_type": "PREFIXED" }
      ],
      "source_acl_ids": [11, 12]
    }
  ]
}
Terminal
RUN=runs/2026-05-21T10-00-00Zmonedula-acl-rbac extract --from text --input acls.txt --out $RUN/acls.jsonmonedula-acl-rbac plan --acls $RUN/acls.json --rules rules.yaml --principals principals.yaml --scopes scopes.yaml --out $RUN/plan.jsonmonedula-acl-rbac auth login --mds-url https://mds.example.commonedula-acl-rbac apply --plan $RUN/plan.json --mds-url https://mds.example.com --confirmmonedula-acl-rbac verify --plan $RUN/plan.json --mds-url https://mds.example.com# exit 0: every source ACL is still allowed; exit 5: some access is missing or unknown

Auszug aus plan.json in examples/text-dump/expected/ im Repository.

Das Problem

ACLs und RBAC lassen sich nicht eins zu eins abbilden.

Einen bestehenden Cluster auf Confluent RBAC umzustellen heißt, jede ACL in eine Rollenbindung zu verwandeln. Manche ACLs, etwa DENY-Regeln, sollten gar nicht konvertiert werden, andere passen zu keiner Abbildungsregel, und ein Binding kann sich sauber anwenden lassen und trotzdem nichts gewähren. Von Hand erledigt, scheitert jeder dieser Fälle stillschweigend.

9
ACL-Quellen, von einem laufenden Cluster bis zu Strimzi- und CFK-Manifesten
3
Wege, Bindings weiterzugeben: Shell-Skript, CFK-Manifest, MDS-curl
~10k
ACLs pro Lauf, im Speicher gehalten

So funktioniert es

  1. 01

    Extrahieren extract

    ACLs aus einer von neun Quellen in eine kanonische acls.json einlesen.

  2. 02

    Planen plan

    Die ACLs mit Standardregeln, die Sie überschreiben können, auf Rollenbindungen abbilden; report.txt lesen.

  3. 03

    Anwenden apply

    Die Bindings in MDS erstellen. Ohne --confirm ändert sich nichts.

  4. 04

    Verifizieren verify

    MDS fragen, ob jede ursprüngliche Berechtigung noch erlaubt ist.

  5. 05

    Aufräumen delete-acls

    Das Löschskript samt Rollback-Skript erzeugen und selbst ausführen.

  1. Quell-ACLs laufender Cluster; kafka-acls-Dump; JSON, YAML, CSV; Strimzi; CFK; Kubernetes
  2. plan.json jede ACL abgebildet, nicht abgebildet oder abgelehnt; mit Prüfsumme
  3. Weg A: apply in MDS, dann den effektiven Zugriff verifizieren
    Weg B: emit Skript, CFK-Manifest, MDS-curl für Ihre Pipeline
  4. Alte ACLs entfernen ein Löschskript, das Sie prüfen und ausführen
Die Quell-ACLs werden zu einem Plan mit Prüfsumme, der in MDS angewendet oder für Ihre Pipeline ausgegeben wird, bevor die alten ACLs entfernt werden.

Effektiver Zugriff, verifiziert

verify fragt MDS für jede Quell-ACL, ob der ursprüngliche Principal, die Operation und die Ressource jetzt tatsächlich erlaubt sind, nicht nur, ob eine Binding-Zeile existiert. Eine falsche Cluster-ID erzeugt Bindings, die sich sauber anwenden lassen und nichts gewähren; genau das fängt diese Prüfung ab.

Terminal
monedula-acl-rbac verify \
  --plan runs/2026-05-21T10-00-00Z/plan.json \
  --mds-url https://mds.example.com \
  --mds-token-file ~/.confluent/token

Jede ACL landet in einer von drei Listen

Der Geltungsbereich wird nie erweitert: Eine präfixierte ACL auf Topic:foo* wird zu einem Binding auf Topic:foo*, nie zu einer clusterweiten Berechtigung. Pläne tragen Prüfsummen, und ein veralteter oder bearbeiteter Plan wird abgelehnt, bis Sie ihn erneut validieren.

bindings
zu erstellende Rollenbindungen, jede mit den IDs der Quell-ACLs, die sie ersetzt
unmapped
ACLs, die keine Regel übersetzen konnte; Sie entscheiden, was damit geschieht
rejected
ACLs, die das Tool nicht konvertiert, etwa DENY-Regeln

Mit MDS-Zugriff oder ohne

Geben Sie dem Tool MDS-Zugriff, und es wendet die Bindings selbst an und verifiziert sie. Oder lassen Sie die MDS-Credentials, wo sie sind: Geben Sie den Plan als Confluent-CLI-Skript, als CFK-Manifeste ConfluentRolebinding oder als MDS-curl-Befehle aus, lassen Sie Ihre Pipeline sie anwenden, und führen Sie verify später auf einem Host mit MDS-Zugriff aus. Für einen schnellen Blick führt convert extract, plan und emit in einem Aufruf aus.

Einen Weg wählen (auf Englisch)

One-Shot-Konvertierung
monedula-acl-rbac convert \
  --from yaml \
  --input acls.yaml \
  --scopes scopes.yaml \
  --rules rules.yaml \
  --principals principals.yaml \
  > bindings.sh

Ein Laufverzeichnis, das Sie einem Auditor zeigen können

Jeder Lauf bewahrt den Eingabe-Snapshot, die wirksamen Regeln, den Plan, die Logs und die Rollback-Skripte in einem Verzeichnis auf, zusammen mit einem Vermerk, welche Credentials-Quelle verwendet wurde. Zwei apply-Läufe können sich im selben Verzeichnis nicht in die Quere kommen.

runs/2026-05-21T10-00-00Z/
  acls.json          source ACL snapshot
  plan.json          checksummed plan
  report.txt         what maps to what, and why
  would-apply.log    dry-run calls
  apply.log          what was created
  verify.json        effective-access results
  delete-acls.sh     generated, run by you

Installation

Go
go install github.com/monedula-dev/monedula-acl-rbac-converter/cmd/monedula-acl-rbac@latest

Release-Archive für Linux, macOS und Windows, mit einer per cosign signierten Prüfsummendatei und einer SBOM, liegen auf der Releases-Seite. Siehe Ein Release installieren und verifizieren (auf Englisch).

Fragen

Ist monedula-acl-rbac-converter kostenlos, und darf ich es bei der Arbeit nutzen?
Ja. Es steht unter der AGPL-3.0, ohne kostenpflichtige Edition, und wenn Sie es in Ihrer eigenen Infrastruktur betreiben, müssen Sie weder Ihren Code noch Ihre Konfiguration offenlegen: Pflichten aus der AGPL greifen, wenn Sie es verbreiten, ob verändert oder nicht, oder anderen ermöglichen, eine veränderte Version über ein Netzwerk zu nutzen.
Löscht es meine ACLs?
Nicht von selbst: apply löscht nie Quell-ACLs, und delete-acls schreibt ein kafka-acls --remove-Skript samt Rollback-Skript, die Sie prüfen und ausführen. Das Skript enthält nur ACLs, die verify bestanden haben; hat keine bestanden, bricht delete-acls mit einem Fehler ab. Siehe Konvertierte ACLs löschen (auf Englisch).
Was passiert mit DENY-ACLs?
Sie werden nie automatisch konvertiert; der Plan führt sie als abgelehnt. delete-deny-acls erzeugt ein Skript, das beim Ausführen die effektiven Berechtigungen für jede ACL erneut prüft, und DENYs mit Wildcard-Principal kann das Tool nie entfernen. Siehe DENY-ACLs entfernen (auf Englisch).
Wie viele ACLs verarbeitet es?
Bis etwa 10.000 ACLs pro Lauf, im Speicher gehalten. Darüber hinaus teilen Sie sie nach Principal auf, mit einem Laufverzeichnis pro Batch.

Support

Hilfe von den Entwicklern des Tools

Wir können Ihnen helfen, monedula-acl-rbac-converter in einer großen Umgebung einzusetzen, vom Design bis zum täglichen Betrieb.

Teil von
Monedula Flock

Weitere kostenlose Tools für Apache Kafka vom selben Team. Über Flock