Article associé : Des ACL Kafka au RBAC Confluent : un chemin de migration sûr avec un nouvel outil open source 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 :

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.