---
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"]
---> **Artículo complementario:** [De las ACL de Kafka al RBAC de Confluent: una ruta de migración segura con una nueva herramienta de código abierto](/blog/kafka-acls-confluent-rbac-migration-monedula-acl-rbac-converter/) explica por qué la migración de ACL a RBAC es más difícil de lo que parece, y el flujo de trabajo paso a paso.

## Por qué

Adoptar el RBAC de Confluent en un clúster de Kafka existente significa traducir
cada ACL nativa en un role binding equivalente, y los dos modelos no se mapean
uno a uno. Hecho a mano, es lento, fácil de equivocarse de forma sutil y difícil
de demostrar correcto después.

`monedula-acl-rbac-converter` hace que esa migración sea mecánica y revisable.
Lee las ACL desde donde estén —un clúster en vivo, un volcado exportado de
`kafka-acls.sh --list`, JSON/YAML/CSV, manifiestos `KafkaUser` de Strimzi o de
Confluent for Kubernetes, un clúster de Kubernetes en ejecución, o un script de
configuración antiguo lleno de comandos `kafka-acls --add`— y produce un plan de
role bindings RBAC de Confluent, con cada paso auditable.

## Cómo funciona

El flujo de producción es explícito y por pasos, de modo que cada etapa produce
artefactos que puedes revisar, versionar o adjuntar a una solicitud de cambio:

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

Se admiten dos modelos operativos, según cuánto quieras que la herramienta
intervenga:

- **Directo (MDS)**: aplica los role bindings directamente al Metadata Service
  de Confluent. El paso de aplicación es idempotente: los bindings existentes se
  omiten.
- **Solo artefactos**: emite scripts de la CLI de Confluent, manifiestos de
  Confluent for Kubernetes o comandos `mds-curl` para que los aplique tu propia
  canalización de GitOps / control de cambios, de modo que nada cambia sin que
  una canalización lo ejecute.

La seguridad es el objetivo: los planes llevan checksum, el acceso efectivo se
verifica tras la aplicación (los nuevos bindings realmente otorgan lo que las
ACL antiguas otorgaban) y la eliminación de las ACL de origen se basa en
scripts: la herramienta genera `delete-acls.sh` más un `rollback.sh`, de modo
que una persona revisa y ejecuta la limpieza de forma deliberada.

## Configurar

La conversión se ajusta con tres archivos YAML opcionales: `scopes.yaml` (los
IDs de los clústeres de Confluent a los que apuntan los bindings), `rules.yaml`
(anulaciones de mapeo personalizadas) y `principals.yaml` (remapeo de
principals). Las ACL DENY no tienen equivalente en RBAC, por lo que no se
convierten en silencio: se reportan y se gestionan por separado.