---
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"]
---> **Article associé :** [Des ACL Kafka au RBAC Confluent : un chemin de migration sûr avec un nouvel outil open source](/blog/kafka-acls-confluent-rbac-migration-monedula-acl-rbac-converter/) explique pourquoi la migration des ACL vers le RBAC est plus difficile qu'il n'y paraît, et détaille le workflow étape par étape.

## Pourquoi

Adopter le RBAC Confluent sur un cluster Kafka existant signifie traduire chaque
ACL native en un binding de rôle équivalent — et les deux modèles ne se mappent
pas un pour un. Fait à la main, c'est lent, facile à se tromper subtilement, et
difficile à prouver correct après coup.

`monedula-acl-rbac-converter` rend cette migration mécanique et relisible.
Il lit les ACL d'où qu'elles proviennent — un cluster en production, un export
de `kafka-acls.sh --list`, du JSON/YAML/CSV, des manifestes Strimzi `KafkaUser`
ou Confluent for Kubernetes, un cluster Kubernetes en cours d'exécution, ou un
ancien script de configuration plein de commandes `kafka-acls --add` — et
produit un plan de bindings de rôles RBAC Confluent, chaque étape étant
auditable.

## Comment ça fonctionne

Le workflow de production est explicite et structuré par étapes, de sorte que
chaque phase produit des artefacts que vous pouvez relire, versionner ou
attacher à une demande de changement :

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

Deux modèles d'exploitation sont pris en charge, selon le degré d'intervention
que vous souhaitez confier à l'outil :

- **Direct (MDS)** — appliquer les bindings de rôles directement au Metadata
  Service de Confluent. L'étape d'application est idempotente : les bindings
  existants sont ignorés.
- **Artefacts uniquement** — émettre des scripts Confluent CLI, des manifestes
  Confluent for Kubernetes ou des commandes `mds-curl` pour que votre propre
  pipeline GitOps / change-control les applique, afin que rien ne change sans
  qu'un pipeline ne l'exécute.

La sécurité est l'objectif : les plans sont protégés par checksum, l'accès
effectif est vérifié après application (les nouveaux bindings accordent
réellement ce que les anciennes ACL accordaient), et la suppression des ACL
sources est basée sur des scripts — l'outil génère `delete-acls.sh` plus un
`rollback.sh`, de sorte qu'un humain relit et exécute le nettoyage
délibérément.

## Configurer

La conversion se règle avec trois fichiers YAML optionnels : `scopes.yaml` (les
identifiants des clusters Confluent ciblés par les bindings), `rules.yaml`
(surcharges de mapping personnalisées) et `principals.yaml` (remappage de
principals). Les ACL DENY n'ont pas d'équivalent RBAC, elles ne sont donc pas
converties silencieusement — elles sont signalées et traitées séparément.