---
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"]
---> **Articolo di accompagnamento:** [Dagli ACL di Kafka all'RBAC di Confluent: un percorso di migrazione sicuro con un nuovo strumento open source](/blog/kafka-acls-confluent-rbac-migration-monedula-acl-rbac-converter/) 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:

```text
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.