Monedula

Cette page a été traduite automatiquement depuis l’anglais. Lire l’original

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

Migrer les ACL Kafka vers le RBAC et vérifier les accès

monedula-acl-rbac-converter lit vos ACL Kafka là où elles se trouvent, planifie les bindings de rôles RBAC Confluent équivalents, les applique, puis demande à MDS si chaque permission d'origine est toujours valable. Ce n'est qu'ensuite qu'il écrit le script qui supprime les anciennes ACL.

Go 
go install github.com/monedula-dev/monedula-acl-rbac-converter/cmd/monedula-acl-rbac@latest
Commencer le tutoriel de migration (en anglais) GitHub
runs/<timestamp>/plan.json (extrait) 
{
  "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

Extrait de plan.json tiré de examples/text-dump/expected/ dans le dépôt.

Le problème

Les ACL et le RBAC ne se mappent pas un pour un.

Passer un cluster existant au RBAC Confluent implique de transformer chaque ACL en binding de rôle. Certaines ACL, comme les règles DENY, ne doivent pas être converties du tout, d'autres ne correspondent à aucune règle de mapping, et un binding peut s'appliquer sans erreur et pourtant ne rien accorder. À la main, chacun de ces cas échoue en silence.

9
sources d'ACL, d'un cluster en production aux manifestes Strimzi et CFK
3
façons de transmettre les bindings : script shell, manifeste CFK, curl MDS
~10k
ACL par exécution, gardées en mémoire

Comment ça fonctionne

  1. 01

    Extraire extract

    Lire les ACL depuis l'une des neuf sources vers un fichier canonique acls.json.

  2. 02

    Planifier plan

    Les mapper vers des bindings de rôles avec des règles par défaut que vous pouvez surcharger ; lire report.txt.

  3. 03

    Appliquer apply

    Créer les bindings dans MDS. Rien ne change sans --confirm.

  4. 04

    Vérifier verify

    Demander à MDS si chaque permission d'origine est toujours autorisée.

  5. 05

    Retirer delete-acls

    Générer le script de suppression, avec son script de rollback, et l'exécuter vous-même.

  1. ACL sources cluster en production ; dump kafka-acls ; JSON, YAML, CSV ; Strimzi ; CFK ; Kubernetes
  2. plan.json chaque ACL mappée, non mappée ou rejetée ; avec checksum
  3. Chemin A : apply vers MDS, puis vérification de l'accès effectif
    Chemin B : emit script, manifeste CFK, curl MDS pour votre pipeline
  4. Retirer les ACL un script de suppression que vous inspectez et exécutez
Les ACL sources deviennent un seul plan avec checksum, qui est appliqué sur MDS ou émis pour votre pipeline avant le retrait des anciennes ACL.

Accès effectif, vérifié

verify demande à MDS, pour chaque ACL source, si le principal, l'opération et la ressource d'origine sont réellement autorisés maintenant, et pas seulement si une ligne de binding existe. Un ID de cluster erroné produit des bindings qui s'appliquent sans erreur et n'accordent rien ; c'est cette vérification qui le détecte.

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

Chaque ACL se retrouve dans l'une des trois listes

La portée n'est jamais élargie : une ACL préfixée sur Topic:foo* devient un binding sur Topic:foo*, jamais une autorisation sur tout le cluster. Les plans sont protégés par checksum, et un plan périmé ou modifié est refusé tant que vous ne l'avez pas revalidé.

bindings
bindings de rôles à créer, chacun listant les ID des ACL sources qu'il remplace
unmapped
ACL qu'aucune règle n'a pu traduire ; vous décidez quoi en faire
rejected
ACL que l'outil ne convertit pas, comme les règles DENY

Avec ou sans accès à MDS

Donnez à l'outil un accès à MDS, et il applique et vérifie les bindings lui-même. Ou laissez les identifiants MDS là où ils sont : émettez le plan sous forme de script Confluent CLI, de manifestes CFK ConfluentRolebinding ou de commandes curl MDS, laissez votre pipeline les appliquer, puis lancez verify plus tard depuis un hôte qui a accès à MDS. Pour un aperçu rapide, convert exécute extract, plan et emit en un seul appel.

Choisir un chemin (en anglais)

conversion tout-en-un 
monedula-acl-rbac convert \
  --from yaml \
  --input acls.yaml \
  --scopes scopes.yaml \
  --rules rules.yaml \
  --principals principals.yaml \
  > bindings.sh

Un répertoire d'exécution à montrer à un auditeur

Chaque exécution conserve l'instantané d'entrée, les règles effectives, le plan, les logs et les scripts de rollback dans un seul répertoire, avec une trace de la source d'identifiants utilisée. Deux exécutions d'apply ne peuvent pas entrer en concurrence sur le même répertoire.

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

Les archives de release pour Linux, macOS et Windows, avec un fichier de checksums signé par cosign et un SBOM, sont sur la page des releases. Voir installer et vérifier une release (en anglais).

Questions

monedula-acl-rbac-converter est-il gratuit, et puis-je l'utiliser au travail ?
Oui. Il est sous licence AGPL-3.0, sans édition payante, et l'exécuter sur votre propre infrastructure ne vous oblige pas à partager votre code ni votre configuration : les obligations de l'AGPL s'appliquent lorsque vous le distribuez, modifié ou non, ou lorsque vous permettez à d'autres d'utiliser une version modifiée via un réseau.
Va-t-il supprimer mes ACL ?
Pas de lui-même : apply ne supprime jamais les ACL sources, et delete-acls écrit un script kafka-acls --remove, avec son rollback, que vous inspectez et exécutez. Le script ne couvre que les ACL validées par verify ; si aucune ne l'est, delete-acls s'arrête sur une erreur. Voir supprimer les ACL converties (en anglais).
Que deviennent les ACL DENY ?
Elles ne sont jamais converties automatiquement ; le plan les liste comme rejetées. delete-deny-acls génère un script qui revérifie les permissions effectives de chaque ACL au moment de son exécution, et les ACL DENY à principal wildcard ne peuvent jamais être supprimées par l'outil. Voir retirer les ACL DENY (en anglais).
Combien d'ACL peut-il traiter ?
Jusqu'à environ 10 000 ACL par exécution, gardées en mémoire. Au-delà, découpez par principal, avec un répertoire d'exécution par lot.

Assistance

L’aide de ceux qui le développent

Nous pouvons vous aider à mettre en œuvre monedula-acl-rbac-converter sur un parc étendu, de la conception à l’exploitation au quotidien.

Parlons-en

Fait partie de
Monedula Flock

D’autres outils gratuits pour Apache Kafka, par la même équipe. À propos de Flock