---
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"]
---> **Post complementar:** [De ACLs do Kafka ao RBAC do Confluent: um caminho de migração seguro com uma nova ferramenta open-source](/blog/kafka-acls-confluent-rbac-migration-monedula-acl-rbac-converter/) explica por que a migração de ACL para RBAC é mais difícil do que parece, e detalha o fluxo passo a passo.

## Por quê

Adotar o RBAC do Confluent em um cluster Kafka existente significa traduzir cada
ACL nativa em um role binding equivalente — e os dois modelos não mapeiam
um-para-um. Feito à mão, é lento, fácil de errar de forma sutil e difícil de
provar correto depois.

O `monedula-acl-rbac-converter` torna essa migração mecânica e revisável.
Ele lê ACLs de onde quer que elas estejam — um cluster ao vivo, um dump
exportado de `kafka-acls.sh --list`, JSON/YAML/CSV, manifests `KafkaUser` do
Strimzi ou do Confluent for Kubernetes, um cluster Kubernetes em execução ou um
antigo script de setup cheio de comandos `kafka-acls --add` — e produz um plano
de role bindings RBAC do Confluent, com cada etapa auditável.

## Como funciona

O fluxo de produção é explícito e baseado em etapas, de modo que cada estágio
produz artefatos que você pode revisar, versionar ou anexar a uma solicitação de
mudança:

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

Dois modelos operacionais são suportados, dependendo de quanto você quer que a
ferramenta toque:

- **Direto (MDS)** — aplica os role bindings diretamente no Metadata Service
  do Confluent. A etapa de aplicação é idempotente: bindings existentes são ignorados.
- **Somente artefatos** — emite scripts da Confluent CLI, manifests do
  Confluent for Kubernetes ou comandos `mds-curl` para o seu próprio pipeline de
  GitOps / controle de mudanças aplicar, de modo que nada muda sem um pipeline executando.

A segurança é o ponto central: os planos têm checksum, o acesso efetivo é verificado após
a aplicação (os novos bindings realmente concedem o que as ACLs antigas concediam), e a exclusão
das ACLs de origem é baseada em script — a ferramenta gera o `delete-acls.sh` mais um
`rollback.sh`, para que um humano revise e execute a limpeza de forma deliberada.

## Configurar

A conversão é ajustada com três arquivos YAML opcionais: `scopes.yaml` (os
IDs de cluster Confluent que os bindings alvejam), `rules.yaml` (overrides de
mapeamento personalizados) e `principals.yaml` (remapeamento de principals). As ACLs DENY não têm
equivalente em RBAC, então não são convertidas silenciosamente — elas são reportadas e tratadas
separadamente.