Dagli ACL di Kafka all'RBAC di Confluent:
un percorso di migrazione sicuro con un nuovo strumento open source

Quando lavoriamo con banche e grandi aziende, Kafka raramente è un argomento greenfield.

Più spesso, Kafka è già in esecuzione da anni. I team ne dipendono, dati critici lo attraversano e la piattaforma ha accumulato una lunga storia di decisioni operative, convenzioni di denominazione, service account, pattern di topic e regole di accesso. Quando un’organizzazione decide di passare a Confluent Platform, Kafka non è più solo un sistema di messaggistica. È parte della spina dorsale della produzione.

Questo contesto è importante, perché le migrazioni in ambienti del genere non sono solo progetti tecnici. Sono esercizi di gestione del rischio.

Nella prima fase di una migrazione verso Confluent, l’approccio più sicuro è solitamente cambiare il meno possibile. L’obiettivo è spostare le fondamenta della piattaforma, stabilizzarle e solo successivamente introdurre miglioramenti più ampi. L’autenticazione e l’autorizzazione fanno parte di questa storia. Le installazioni Kafka esistenti spesso si affidano agli ACL di Apache Kafka, perché gli ACL sono il modello di autorizzazione integrato disponibile nella versione open source di Kafka.

Confluent Platform, tuttavia, fornisce anche l’RBAC: il controllo degli accessi basato sui ruoli. L’RBAC è solitamente più facile da comprendere su scala organizzativa, si adatta meglio alla governance della piattaforma e si integra naturalmente con altri componenti Confluent come Metadata Service, Control Center e Confluent for Kubernetes.

Quindi la domanda diventa: come si passa da un’installazione Kafka esistente basata su ACL all’RBAC di Confluent senza trasformare il controllo degli accessi in una migrazione manuale ad alto rischio?

È esattamente per questo che abbiamo costruito monedula-acl-rbac-converter.

Perché la migrazione da ACL a RBAC è più difficile di quanto sembri

Un piccolo cluster Kafka con una manciata di topic e utenti può essere migrato manualmente. Ispezioni gli ACL, decidi i ruoli RBAC equivalenti, crei i binding, verifichi l’accesso e rimuovi i vecchi ACL.

Ma non è così che si presentano la maggior parte degli ambienti enterprise maturi.

Nelle installazioni reali, puoi trovare centinaia o migliaia di regole ACL. Alcune sono state create dai team di piattaforma. Altre dai team applicativi. Alcune provengono dall’automazione. Alcune sono vecchie ma ancora utilizzate. Alcune usano pattern di topic con prefisso. Alcune fanno riferimento a service user che nel frattempo sono stati rinominati. Alcune sono state esportate da script che nessuno tocca da anni.

La migrazione manuale in questo contesto presenta diversi problemi:

• è lenta,
• è soggetta a errori,
• è difficile da revisionare,
• è difficile da ripetere,
• è difficile da verificare,
• e diventa pericolosa quando inizia la pulizia.

Creare nuovi binding RBAC è solo metà della migrazione. La parte più delicata è dimostrare che i nuovi binding forniscono lo stesso accesso effettivo dei vecchi ACL, e solo allora rimuovere gli ACL di origine.

Ecco perché non volevamo uno strumento che si limitasse a “tradurre un file”. Volevamo un flusso di migrazione.

Cosa fa il converter

monedula-acl-rbac-converter è uno strumento da riga di comando che legge gli ACL Kafka esistenti, li converte in un piano di binding di ruoli RBAC di Confluent e aiuta gli operatori a eseguire la migrazione in modo controllato e verificabile.

Può leggere gli ACL da molteplici sorgenti del mondo reale, tra cui:

• un cluster Kafka attivo,
• l’output esportato di kafka-acls.sh --list,
• dump JSON, YAML o CSV,
• manifest KafkaUser di Strimzi,
• manifest di Confluent for Kubernetes,
• un cluster Kubernetes in esecuzione,
• oppure uno shell script contenente comandi kafka-acls --add ....

Quest’ultimo caso è particolarmente utile negli ambienti brownfield. Molti team non partono da un’esportazione pulita. Hanno invece un vecchio script di configurazione che ha creato gli ACL in origine.

Per esempio, uno script di input può contenere comandi come:

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

Il converter può estrarre queste definizioni ACL in un file canonico acls.json. Da lì, può produrre un piano di migrazione revisionato, emettere script o manifest, applicare i binding direttamente a Confluent MDS, verificare il risultato e generare script di pulizia per i vecchi ACL.

Un flusso di lavoro progettato per cambiamenti ad alto rischio

Le migrazioni del controllo degli accessi necessitano di protezioni. Un permesso errato può interrompere i carichi di lavoro in produzione. Un permesso troppo ampio può creare un incidente di sicurezza. Un passo di pulizia eseguito troppo presto può causare un’interruzione del servizio.

Per questo motivo, il flusso di lavoro di produzione è esplicito e suddiviso in passi:

1. extract       -> creare uno snapshot ACL canonico
2. plan          -> convertire le ACL in un piano di migrazione RBAC
3. apply dry-run -> visualizzare in anteprima le modifiche MDS
4. apply         -> creare role binding RBAC
5. verify        -> verificare l'accesso effettivo
6. wait          -> lasciare che gli utenti provino il nuovo percorso
7. delete-acls   -> generare uno script di eliminazione per le vecchie ACL
8. review + run  -> eseguire manualmente il cleanup

Ogni passo crea artefatti che possono essere ispezionati, revisionati, versionati o allegati a una richiesta di modifica.

Lo strumento separa intenzionalmente la pianificazione dall’applicazione, l’applicazione dalla verifica e la verifica dall’eliminazione. Questo rende la migrazione più facile da comprendere e più sicura da eseguire in ambienti regolamentati.

Esempio: migrazione da uno script di configurazione ACL

Supponiamo che il punto di partenza sia uno shell script con comandi kafka-acls.sh --add.

1. Estrazione degli ACL

Per prima cosa, estrai gli ACL in una rappresentazione JSON canonica:

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

Il file opzionale vars.yaml è utile quando lo script contiene variabili. Lo strumento non indovina i valori non risolti. Se sono presenti variabili, dovrebbero essere fornite esplicitamente oppure lo script dovrebbe essere pre-espanso prima della migrazione.

In questa fase, l’output è ancora solo uno snapshot. Nessuno stato esterno viene modificato.

2. Creazione di un piano di migrazione

Successivamente, converti gli ACL estratti in un piano di binding di ruoli:

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

Il file scopes.yaml identifica i cluster Confluent verso cui i binding RBAC dovrebbero essere indirizzati. I file opzionali rules.yaml e principals.yaml consentono agli operatori di adattare la conversione al proprio ambiente, per esempio mappando i principal di origine al formato di principal atteso da MDS.

Il passo di pianificazione genera anche un report. Questo è uno dei punti di revisione più importanti del flusso di lavoro. Mostra in cosa è diventato ogni ACL di origine e segnala tutto ciò che non è stato possibile mappare o che non dovrebbe essere convertito automaticamente.

3. Lettura del report

Prima che venga applicato qualsiasi cosa, gli operatori dovrebbero leggere il report generato.

È qui che il lavoro di migrazione diventa visibile. Invece di affidarsi a una conversione a scatola chiusa, il team può revisionare i binding generati, indagare sugli ACL non mappati e decidere se sono necessarie regole di mappatura personalizzate.

Gli ACL di tipo DENY meritano un’attenzione particolare. L’RBAC di Confluent non ha una semantica di deny equivalente, quindi gli ACL DENY non vengono convertiti silenziosamente. Vengono segnalati e gestiti separatamente.

4. Dry-run del passo di applicazione

Prima di creare i binding di ruoli in MDS, esegui 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

Il dry-run mostra un’anteprima delle chiamate MDS che verrebbero effettuate. Esegue inoltre dei controlli in lettura, in modo che i binding esistenti possano essere saltati in modo idempotente.

Questo offre agli operatori un altro punto di controllo prima della prima modifica reale.

5. Applicazione dei binding RBAC

Una volta revisionato l’output del dry-run, applica il piano:

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

Il passo di applicazione crea i binding RBAC in Confluent MDS. È progettato per essere rieseguibile: se un binding esiste già, viene saltato.

6. Verifica dell’accesso effettivo

Dopo aver applicato i binding RBAC, verifica che concedano effettivamente l’accesso originariamente fornito dagli ACL:

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

Questo è più rigoroso che controllare se un binding esiste. L’obiettivo è confermare l’accesso effettivo per il principal, l’operazione e la risorsa originali.

Questa distinzione è importante negli ambienti enterprise, dove la propagazione dell’identità, l’appartenenza a un gruppo, l’integrazione LDAP o le discrepanze di scope possono far sì che un binding esista ma non si comporti come previsto.

7. Generazione degli script di eliminazione degli ACL

Solo dopo una verifica riuscita, e dopo un periodo di attesa definito dall’operatore, gli ACL di origine dovrebbero essere rimossi.

Lo strumento non elimina gli ACL direttamente. Genera invece uno script che gli operatori ispezionano ed eseguono autonomamente:

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

Gli artefatti generati includono:

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

Si tratta di un deliberato punto di controllo umano. L’operatore può aprire lo script, revisionare ogni comando kafka-acls --remove, eseguirlo per un principal alla volta e conservare lo script di rollback fino a quando la migrazione non è stabile.

Output diversi per modelli operativi diversi

Non tutte le organizzazioni vogliono lo stesso modello di applicazione.

Alcuni team si sentono a proprio agio nell’applicare direttamente a MDS. Altri hanno bisogno che ogni modifica passi attraverso un processo di change-control, un flusso GitOps o una pipeline CD esterna.

Il converter supporta questi scenari emettendo diversi tipi di artefatti:

# Script shell con comandi di role binding Confluent CLI
monedula-acl-rbac emit \
  --plan runs/billing-batch-1/plan.json \
  --format script \
  --out-dir emit/

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

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

Questo rende lo strumento utile sia per il lavoro di migrazione pratico sia per gli ambienti in cui le modifiche all’infrastruttura devono passare attraverso un sistema separato di approvazione e deployment.

Costruito per il caos reale delle migrazioni

Abbiamo cercato di supportare i tipi di input e vincoli che emergono nelle installazioni Kafka reali, non solo i casi demo puliti.

Questo include:

• estrazione da Kafka attivo,
• esportazioni testuali,
• file strutturati,
• risorse native di Kubernetes,
• manifest di Confluent for Kubernetes esistenti,
• vecchi script di configurazione,
• rimappatura dei principal,
• regole di conversione personalizzate,
• esecuzione in dry-run,
• applicazione diretta su MDS,
• script e manifest emessi,
• verifica dell’accesso effettivo,
• generazione di script di eliminazione,
• artefatti di rollback,
• e comandi di status/diff per batch di migrazione ripetibili.

Il risultato è uno strumento utilizzabile sia per l’esplorazione sia per migrazioni di livello produttivo.

Per piccoli esperimenti, il comando one-shot convert può eseguire estrazione, pianificazione ed emissione di script in un unico passo:

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

Per la produzione, la pipeline esplicita è il percorso consigliato perché preserva gli artefatti di audit e i punti di revisione.

Considerazioni finali

Migrare dagli ACL di Kafka all’RBAC di Confluent non è solo un problema di conversione sintattica.

È un cambiamento controllato del modello di autorizzazione di una piattaforma dati in esecuzione. Nelle grandi organizzazioni, specialmente nel settore bancario e nei settori regolamentati, quel cambiamento deve essere revisionabile, ripetibile, verificabile e reversibile dove possibile.

Abbiamo costruito monedula-acl-rbac-converter perché continuavamo a vedere lo stesso schema: Kafka era già presente, gli ACL erano già presenti e i team volevano adottare l’RBAC di Confluent senza tradurre manualmente centinaia di regole sotto la pressione della migrazione.

Lo strumento non è pensato per nascondere il processo di migrazione. È pensato per renderlo visibile.

Estrai lo stato attuale. Pianifica lo stato di destinazione. Revisiona il report. Esegui le modifiche in dry-run. Applica con cautela. Verifica l’accesso effettivo. Genera gli script di pulizia. Revisionali. Poi rimuovi i vecchi ACL solo quando sei pronto.

Questo è il tipo di flusso di lavoro che desideriamo per le migrazioni del controllo degli accessi.

L’abbiamo costruito perché è utile per noi. Speriamo che sarà utile anche per gli altri.

Puoi trovare monedula-acl-rbac-converter su GitHub. Se trovi un bug o hai un suggerimento per migliorarlo, sentiti libero di aprire una issue.