Des ACL Kafka au RBAC Confluent : un chemin de migration sûr avec un nouvel outil open source

Lorsque nous travaillons avec des banques et de grandes entreprises, Kafka est rarement un sujet greenfield.

Le plus souvent, Kafka tourne déjà depuis des années. Les équipes en dépendent, des données critiques y transitent, et la plateforme a accumulé une longue histoire de décisions opérationnelles, de conventions de nommage, de comptes de service, de patterns de topics et de règles d’accès. Au moment où une organisation décide de passer à Confluent Platform, Kafka n’est plus seulement un système de messagerie. Il fait partie de la colonne vertébrale de production.

Ce contexte a son importance, car les migrations dans de tels environnements ne sont pas seulement des projets techniques. Ce sont des exercices de gestion des risques.

Dans la première phase d’une migration Confluent, l’approche la plus sûre consiste généralement à changer le moins de choses possible. L’objectif est de migrer la fondation de la plateforme, de la stabiliser, et seulement ensuite d’introduire des améliorations plus importantes. L’authentification et l’autorisation font partie de cette histoire. Les installations Kafka existantes s’appuient souvent sur les ACL Apache Kafka, car les ACL constituent le modèle d’autorisation intégré disponible dans Kafka open source.

Confluent Platform fournit toutefois aussi le RBAC : contrôle d’accès basé sur les rôles. Le RBAC est généralement plus facile à appréhender à l’échelle d’une organisation, s’intègre mieux à la gouvernance de plateforme et se combine naturellement avec d’autres composants Confluent comme Metadata Service, Control Center et Confluent for Kubernetes.

La question devient donc : comment passer d’un parc Kafka existant basé sur les ACL au RBAC Confluent sans transformer le contrôle d’accès en une migration manuelle à haut risque ?

C’est exactement la raison pour laquelle nous avons construit monedula-acl-rbac-converter.

Pourquoi la migration des ACL vers le RBAC est plus difficile qu’il n’y paraît

Un petit cluster Kafka avec une poignée de topics et d’utilisateurs peut être migré manuellement. Vous inspectez les ACL, décidez des rôles RBAC équivalents, créez les bindings, vérifiez l’accès et supprimez les anciennes ACL.

Mais ce n’est pas à cela que ressemblent la plupart des environnements d’entreprise matures.

Dans les déploiements réels, vous pouvez trouver des centaines, voire des milliers de règles ACL. Certaines ont été créées par les équipes de plateforme. D’autres par les équipes applicatives. Certaines proviennent de l’automatisation. Certaines sont anciennes mais toujours utilisées. Certaines utilisent des patterns de topics préfixés. Certaines référencent des comptes de service qui ont depuis été renommés. Certaines ont été exportées à partir de scripts auxquels personne n’a touché depuis des années.

La migration manuelle dans ce contexte présente plusieurs problèmes :

elle est lente,
elle est sujette aux erreurs,
elle est difficile à relire,
elle est difficile à reproduire,
elle est difficile à auditer,
et elle devient dangereuse lorsque le nettoyage commence.

Créer de nouveaux bindings RBAC n’est que la moitié de la migration. La partie la plus délicate consiste à prouver que les nouveaux bindings fournissent le même accès effectif que les anciennes ACL, et seulement ensuite à supprimer les ACL sources.

C’est pourquoi nous ne voulions pas d’un outil qui se contente de « traduire un fichier ». Nous voulions un workflow de migration.

Ce que fait le convertisseur

monedula-acl-rbac-converter est un outil en ligne de commande qui lit les ACL Kafka existantes, les convertit en un plan de bindings de rôles RBAC Confluent et aide les opérateurs à exécuter la migration de manière contrôlée et auditable.

Il peut lire les ACL depuis plusieurs sources réelles, notamment :

un cluster Kafka en production,
la sortie exportée de kafka-acls.sh --list,
des dumps JSON, YAML ou CSV,
des manifestes Strimzi KafkaUser,
des manifestes Confluent for Kubernetes,
un cluster Kubernetes en cours d’exécution,
ou un script shell contenant des commandes kafka-acls --add ....

Ce dernier cas est particulièrement utile dans les environnements brownfield. De nombreuses équipes ne partent pas d’un export propre. À la place, elles disposent d’un ancien script de configuration qui a créé les ACL à l’origine.

Par exemple, un script d’entrée peut contenir des commandes comme :

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

Le convertisseur peut extraire ces définitions d’ACL dans un fichier canonique acls.json. À partir de là, il peut produire un plan de migration relu, émettre des scripts ou des manifestes, appliquer les bindings directement à Confluent MDS, vérifier le résultat et générer des scripts de nettoyage pour les anciennes ACL.

Un workflow conçu pour les changements à haut risque

Les migrations de contrôle d’accès ont besoin de garde-fous. Une mauvaise permission peut casser des charges de production. Une permission trop large peut créer un incident de sécurité. Une étape de nettoyage effectuée trop tôt peut provoquer une interruption de service.

Pour cette raison, le workflow de production est explicite et structuré par étapes :

1. extract       -> créer un instantané ACL canonique
2. plan          -> convertir les ACLs en plan de migration RBAC
3. apply dry-run -> prévisualiser les changements MDS
4. apply         -> créer les role bindings RBAC
5. verify        -> vérifier l'accès effectif
6. wait          -> laisser les utilisateurs tester le nouveau chemin
7. delete-acls   -> générer un script de suppression pour les anciennes ACLs
8. review + run  -> exécuter le nettoyage manuellement

Chaque étape crée des artefacts qui peuvent être inspectés, relus, versionnés ou attachés à une demande de changement.

L’outil sépare intentionnellement la planification de l’application, l’application de la vérification, et la vérification de la suppression. Cela rend la migration plus facile à appréhender et plus sûre à exécuter dans des environnements réglementés.

Exemple : migration depuis un script de configuration d’ACL

Supposons que le point de départ soit un script shell contenant des commandes kafka-acls.sh --add.

1. Extraire les ACL

Commencez par extraire les ACL dans une représentation JSON canonique :

monedula-acl-rbac extract \
  --from script \
  --input setup-acls.sh \
  --vars vars.yaml \
  --out runs/billing-batch-1/acls.json

Le fichier optionnel vars.yaml est utile lorsque le script contient des variables. L’outil ne devine pas les valeurs non résolues. Si des variables sont présentes, elles doivent être fournies explicitement, ou le script doit être pré-développé avant la migration.

À ce stade, la sortie n’est encore qu’un instantané. Aucun état externe n’est modifié.

2. Créer un plan de migration

Ensuite, convertissez les ACL extraites en un plan de bindings de rôles :

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

Le fichier scopes.yaml identifie les clusters Confluent que les bindings RBAC doivent cibler. Les fichiers optionnels rules.yaml et principals.yaml permettent aux opérateurs d’adapter la conversion à leur environnement, par exemple en mappant les principals sources vers le format de principal attendu par MDS.

L’étape de planification génère également un rapport. C’est l’un des points de relecture les plus importants du workflow. Il montre ce qu’est devenue chaque ACL source et signale tout ce qui n’a pas pu être mappé ou qui ne devrait pas être converti automatiquement.

3. Lire le rapport

Avant d’appliquer quoi que ce soit, les opérateurs devraient lire le rapport généré.

C’est là que le travail de migration devient visible. Au lieu de s’appuyer sur une conversion en boîte noire, l’équipe peut relire les bindings générés, investiguer les ACL non mappées et décider si des règles de mapping personnalisées sont nécessaires.

Les ACL DENY méritent une attention particulière. Le RBAC Confluent ne possède pas de sémantique de refus équivalente, c’est pourquoi les ACL DENY ne sont pas converties silencieusement. Elles sont signalées et traitées séparément.

4. Effectuer un dry-run de l’étape d’application

Avant de créer des bindings de rôles dans MDS, lancez un dry-run :

monedula-acl-rbac apply \
  --plan runs/billing-batch-1/plan.json \
  --mds-url https://mds.example.com \
  --mds-token-file ~/.confluent/token \
  --dry-run

Le dry-run prévisualise les appels MDS qui seraient effectués. Il réalise également des vérifications en lecture afin que les bindings existants puissent être ignorés de manière idempotente.

Cela donne aux opérateurs un point de contrôle supplémentaire avant le premier changement réel.

5. Appliquer les bindings RBAC

Une fois la sortie du dry-run relue, appliquez le plan :

monedula-acl-rbac apply \
  --plan runs/billing-batch-1/plan.json \
  --mds-url https://mds.example.com \
  --mds-token-file ~/.confluent/token \
  --confirm

L’étape d’application crée les bindings RBAC dans Confluent MDS. Elle est conçue pour être réexécutable : si un binding existe déjà, il est ignoré.

6. Vérifier l’accès effectif

Après avoir appliqué les bindings RBAC, vérifiez qu’ils accordent réellement l’accès initialement fourni par les ACL :

monedula-acl-rbac verify \
  --plan runs/billing-batch-1/plan.json \
  --mds-url https://mds.example.com \
  --mds-token-file ~/.confluent/token

C’est plus rigoureux que de vérifier l’existence d’un binding. L’objectif est de confirmer l’accès effectif pour le principal, l’opération et la ressource d’origine.

Cette distinction est importante dans les environnements d’entreprise où la propagation d’identité, l’appartenance à des groupes, l’intégration LDAP ou des incohérences de scope peuvent faire qu’un binding existe sans se comporter comme attendu.

7. Générer les scripts de suppression des ACL

Ce n’est qu’après une vérification réussie, et après une période de refroidissement définie par l’opérateur, que les ACL sources devraient être supprimées.

L’outil ne supprime pas les ACL directement. À la place, il génère un script que les opérateurs inspectent et exécutent eux-mêmes :

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

Les artefacts générés incluent :

delete-acls.sh
deleted-acls.json
rollback.sh

Il s’agit d’un point de contrôle humain délibéré. L’opérateur peut ouvrir le script, relire chaque commande kafka-acls --remove, l’exécuter pour un principal à la fois, et conserver le script de rollback jusqu’à ce que la migration soit stable.

Des sorties différentes pour des modèles d’exploitation différents

Toutes les organisations ne veulent pas le même modèle d’application.

Certaines équipes sont à l’aise avec une application directe sur MDS. D’autres ont besoin que chaque changement passe par un processus de change-control, un flux GitOps ou un pipeline CD externe.

Le convertisseur prend en charge ces scénarios en émettant différents types d’artefacts :

# Script shell avec les commandes de role bindings Confluent CLI
monedula-acl-rbac emit \
  --plan runs/billing-batch-1/plan.json \
  --format script \
  --out-dir emit/

# Manifestes Confluent for Kubernetes
monedula-acl-rbac emit \
  --plan runs/billing-batch-1/plan.json \
  --format cfk \
  --out-dir emit/

# Commandes curl vers MDS REST API
monedula-acl-rbac emit \
  --plan runs/billing-batch-1/plan.json \
  --format mds-curl \
  --out-dir emit/

Cela rend l’outil utile à la fois pour le travail de migration en direct et pour les environnements où les changements d’infrastructure doivent passer par un système d’approbation et de déploiement distinct.

Conçu pour le désordre réel des migrations

Nous avons essayé de prendre en charge les types d’entrées et de contraintes que l’on rencontre dans les véritables parcs Kafka, et pas seulement des cas de démo propres.

Cela inclut :

l’extraction depuis un Kafka en production,
les exports texte,
les fichiers structurés,
les ressources natives Kubernetes,
les manifestes Confluent for Kubernetes existants,
les anciens scripts de configuration,
le remappage de principals,
les règles de conversion personnalisées,
l’exécution en dry-run,
l’application directe sur MDS,
les scripts et manifestes émis,
la vérification de l’accès effectif,
la génération de scripts de suppression,
les artefacts de rollback,
et des commandes de statut/diff pour des lots de migration reproductibles.

Le résultat est un outil utilisable aussi bien pour l’exploration que pour des migrations de qualité production.

Pour de petites expérimentations, la commande tout-en-un convert peut exécuter l’extraction, la planification et l’émission de scripts en une seule étape :

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

Pour la production, le pipeline explicite est la voie recommandée, car il préserve les artefacts d’audit et les points de relecture.

Pour conclure

Migrer des ACL Kafka vers le RBAC Confluent n’est pas seulement un problème de conversion de syntaxe.

C’est un changement contrôlé du modèle d’autorisation d’une plateforme de données en production. Dans les grandes organisations, en particulier dans la banque et les secteurs réglementés, ce changement doit être relisible, reproductible, auditable et réversible lorsque c’est possible.

Nous avons construit monedula-acl-rbac-converter parce que nous voyions sans cesse le même schéma : Kafka était déjà là, les ACL étaient déjà là, et les équipes voulaient adopter le RBAC Confluent sans traduire manuellement des centaines de règles sous la pression d’une migration.

L’outil n’a pas pour but de masquer le processus de migration. Il a pour but de le rendre visible.

Extrayez l’état actuel. Planifiez l’état cible. Relisez le rapport. Effectuez un dry-run des changements. Appliquez délibérément. Vérifiez l’accès effectif. Générez les scripts de nettoyage. Relisez-les. Puis ne supprimez les anciennes ACL que lorsque vous êtes prêt.

C’est le type de workflow que nous souhaitons pour les migrations de contrôle d’accès.

Nous l’avons construit parce qu’il nous est utile. Nous espérons qu’il sera utile à d’autres également.

Vous pouvez trouver monedula-acl-rbac-converter sur GitHub. Si vous trouvez un bug ou avez une suggestion d’amélioration, n’hésitez pas à ouvrir une issue.