Articolo di accompagnamento: Dagli ACL di Kafka all’RBAC di Confluent: un percorso di migrazione sicuro con un nuovo strumento open source illustra perché la migrazione da ACL a RBAC è più difficile di quanto sembri, e il flusso di lavoro passo dopo passo.

Perché

Adottare l’RBAC di Confluent su un cluster Kafka esistente significa tradurre ogni ACL nativo in un binding di ruolo equivalente — e i due modelli non si mappano uno a uno. Fatto a mano è lento, facile da sbagliare in modo sottile e difficile da dimostrare corretto a posteriori.

monedula-acl-rbac-converter rende quella migrazione meccanica e revisionabile. Legge gli ACL ovunque si trovino — un cluster attivo, un dump esportato di kafka-acls.sh --list, JSON/YAML/CSV, manifest KafkaUser di Strimzi o di Confluent for Kubernetes, un cluster Kubernetes in esecuzione, o un vecchio script di configurazione pieno di comandi kafka-acls --add — e produce un piano di binding di ruoli RBAC di Confluent, con ogni passo verificabile.

Come funziona

Il flusso di lavoro di produzione è esplicito e suddiviso in passi, quindi ogni fase produce artefatti che puoi revisionare, versionare o allegare a una richiesta di modifica:

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

Sono supportati due modelli operativi, a seconda di quanto vuoi che lo strumento intervenga:

  • Diretto (MDS) — applica i binding di ruoli direttamente al Metadata Service di Confluent. Il passo di applicazione è idempotente: i binding esistenti vengono saltati.
  • Solo artefatti — emette script per la Confluent CLI, manifest di Confluent for Kubernetes o comandi mds-curl da applicare tramite la tua pipeline GitOps / di change-control, così nulla cambia senza che sia una pipeline a eseguirlo.

La sicurezza è il punto centrale: i piani sono protetti da checksum, l’accesso effettivo viene verificato dopo l’applicazione (i nuovi binding concedono davvero ciò che concedevano i vecchi ACL), e l’eliminazione degli ACL di origine è basata su script — lo strumento genera delete-acls.sh più uno rollback.sh, in modo che un umano revisioni ed esegua la pulizia deliberatamente.

Configurazione

La conversione è regolata con tre file YAML opzionali: scopes.yaml (gli ID dei cluster Confluent a cui i binding sono indirizzati), rules.yaml (override di mappatura personalizzati) e principals.yaml (rimappatura dei principal). Gli ACL DENY non hanno equivalente RBAC, quindi non vengono convertiti silenziosamente — vengono segnalati e gestiti separatamente.