Monedula

Questa pagina è stata tradotta automaticamente dall'inglese. Leggi l'originale

monedula-acl-rbac-converter v0.10.0, AGPL-3.0

Migra le ACL di Kafka a RBAC e verifica l'accesso

monedula-acl-rbac-converter legge le tue ACL di Kafka ovunque si trovino, pianifica i role binding RBAC di Confluent equivalenti, li applica e chiede a MDS se ogni permesso originale è ancora valido. Solo allora scrive lo script che elimina le vecchie ACL.

Go 
go install github.com/monedula-dev/monedula-acl-rbac-converter/cmd/monedula-acl-rbac@latest
Inizia il tutorial di migrazione (in inglese) GitHub
runs/<timestamp>/plan.json (estratto) 
{
  "schema_version": "1",
  "bindings": [
    {
      "id": "rb-b6fac2ae9aa0",
      "action": "CREATE",
      "principal": "User:svc-analytics",
      "role": "DeveloperRead",
      "scope": { "kafka_cluster": "lkc-demo-1" },
      "resource_patterns": [
        { "resource_type": "Topic", "name": "events.", "pattern_type": "PREFIXED" }
      ],
      "source_acl_ids": [11, 12]
    }
  ]
}
terminale
RUN=runs/2026-05-21T10-00-00Zmonedula-acl-rbac extract --from text --input acls.txt --out $RUN/acls.jsonmonedula-acl-rbac plan --acls $RUN/acls.json --rules rules.yaml --principals principals.yaml --scopes scopes.yaml --out $RUN/plan.jsonmonedula-acl-rbac auth login --mds-url https://mds.example.commonedula-acl-rbac apply --plan $RUN/plan.json --mds-url https://mds.example.com --confirmmonedula-acl-rbac verify --plan $RUN/plan.json --mds-url https://mds.example.com# exit 0: every source ACL is still allowed; exit 5: some access is missing or unknown

Estratto di plan.json da examples/text-dump/expected/ nel repository.

Il problema

ACL e RBAC non si mappano uno a uno.

Portare un cluster esistente su RBAC di Confluent significa trasformare ogni ACL in un role binding. Alcune ACL, come le regole DENY, non vanno convertite affatto, altre non corrispondono a nessuna regola di mappatura, e un binding può applicarsi senza errori e comunque non concedere nulla. Fatto a mano, ognuno di questi casi fallisce in silenzio.

9
sorgenti di ACL, da un cluster in esecuzione ai manifest Strimzi e CFK
3
modi per consegnare i binding: script shell, manifest CFK, curl verso MDS
~10k
ACL per esecuzione, tenute in memoria

Come funziona

  1. 01

    Estrarre extract

    Leggi le ACL da una qualsiasi delle nove sorgenti e raccoglile in un acls.json canonico.

  2. 02

    Pianificare plan

    Mappale su role binding con regole predefinite che puoi sovrascrivere; leggi report.txt.

  3. 03

    Applicare apply

    Crea i binding in MDS. Nulla cambia senza --confirm.

  4. 04

    Verificare verify

    Chiedi a MDS se ogni permesso originale è ancora concesso.

  5. 05

    Dismettere delete-acls

    Genera lo script di eliminazione, con il relativo rollback, ed eseguilo tu stesso.

  1. ACL di origine cluster in esecuzione; dump di kafka-acls; JSON, YAML, CSV; Strimzi; CFK; Kubernetes
  2. plan.json ogni ACL mappata, non mappata o rifiutata; con checksum
  3. Percorso A: apply su MDS, poi verifica dell'accesso effettivo
    Percorso B: emit script, manifest CFK, curl verso MDS per la tua pipeline
  4. Dismettere le ACL uno script di eliminazione che ispezioni ed esegui tu
Le ACL di origine diventano un unico piano con checksum, che viene applicato su MDS o emesso per la tua pipeline prima che le vecchie ACL vengano dismesse.

Accesso effettivo, verificato

verify chiede a MDS, per ogni ACL di origine, se il principal, l'operazione e la risorsa originali sono davvero consentiti ora, non solo se esiste una riga di binding. Un cluster ID non corrispondente produce binding che si applicano senza errori e non concedono nulla; è questo il controllo che lo intercetta.

terminale 
monedula-acl-rbac verify \
  --plan runs/2026-05-21T10-00-00Z/plan.json \
  --mds-url https://mds.example.com \
  --mds-token-file ~/.confluent/token

Ogni ACL finisce in una di tre liste

L'ambito non viene mai allargato: un'ACL con prefisso su Topic:foo* diventa un binding su Topic:foo*, mai un permesso su tutto il cluster. I piani sono protetti da checksum, e un piano obsoleto o modificato viene rifiutato finché non lo convalidi di nuovo.

bindings
role binding da creare, ognuno con gli ID delle ACL di origine che sostituisce
unmapped
ACL che nessuna regola è riuscita a tradurre; decidi tu cosa farne
rejected
ACL che lo strumento non converte, come le regole DENY

Con accesso a MDS, o senza

Dai allo strumento l'accesso a MDS e applicherà e verificherà i binding da solo. Oppure lascia le credenziali MDS dove sono: emetti il piano come script della Confluent CLI, manifest CFK ConfluentRolebinding o comandi curl verso MDS, lascia che sia la tua pipeline ad applicarli e poi esegui verify da un host che ha accesso a MDS. Per un'occhiata veloce, convert esegue extract, plan ed emit in una sola chiamata.

Scegliere un percorso (in inglese)

conversione in un solo passo 
monedula-acl-rbac convert \
  --from yaml \
  --input acls.yaml \
  --scopes scopes.yaml \
  --rules rules.yaml \
  --principals principals.yaml \
  > bindings.sh

Una directory di esecuzione da mostrare a un auditor

Ogni esecuzione conserva lo snapshot di input, le regole effettive, il piano, i log e gli script di rollback in un'unica directory, annotando quale sorgente di credenziali è stata usata. Due esecuzioni di apply non possono contendersi la stessa directory.

runs/2026-05-21T10-00-00Z/
  acls.json          source ACL snapshot
  plan.json          checksummed plan
  report.txt         what maps to what, and why
  would-apply.log    dry-run calls
  apply.log          what was created
  verify.json        effective-access results
  delete-acls.sh     generated, run by you

Installazione

Go 
go install github.com/monedula-dev/monedula-acl-rbac-converter/cmd/monedula-acl-rbac@latest

Gli archivi di release per Linux, macOS e Windows, con un file di checksum firmato con cosign e un SBOM, sono nella pagina delle release. Vedi installare e verificare una release (in inglese).

Domande

monedula-acl-rbac-converter è gratuito e posso usarlo al lavoro?
Sì. È sotto licenza AGPL-3.0, senza edizioni a pagamento, ed eseguirlo sulla tua infrastruttura non ti obbliga a condividere il tuo codice o la tua configurazione: gli obblighi della AGPL si applicano quando lo distribuisci, modificato o meno, o permetti ad altri di usarne una versione modificata attraverso una rete.
Eliminerà le mie ACL?
Non da solo: apply non elimina mai le ACL di origine, e delete-acls scrive uno script kafka-acls --remove, con il relativo rollback, che ispezioni ed esegui tu. Lo script include solo le ACL che hanno superato verify; se nessuna lo ha superato, delete-acls si ferma con un errore. Vedi eliminare le ACL convertite (in inglese).
Che fine fanno le ACL DENY?
Non vengono mai convertite automaticamente; il piano le elenca come rifiutate. delete-deny-acls genera uno script che, quando viene eseguito, ricontrolla i permessi effettivi per ogni ACL, e le DENY con principal wildcard non possono mai essere rimosse dallo strumento. Vedi rimuovere le ACL DENY (in inglese).
Quante ACL riesce a gestire?
Fino a circa 10.000 ACL per esecuzione, tenute in memoria. Oltre questa soglia, suddividi per principal, con una directory di esecuzione per batch.

Supporto

Aiuto da chi sviluppa lo strumento

Possiamo aiutarti a gestire monedula-acl-rbac-converter su un'infrastruttura estesa, dalla progettazione all'operatività quotidiana.

Parliamone

Parte di
Monedula Flock

Altri strumenti gratuiti per Apache Kafka, dallo stesso team. Informazioni su Flock