---
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"]
---> **Powiązany wpis:** [Od Kafka ACL do Confluent RBAC: bezpieczna ścieżka migracji z nowym narzędziem open-source](/blog/kafka-acls-confluent-rbac-migration-monedula-acl-rbac-converter/) przeprowadza przez to, dlaczego migracja z ACL do RBAC jest trudniejsza, niż się wydaje, oraz przez krok po kroku opisany przepływ.

## Dlaczego

Przyjęcie Confluent RBAC na istniejącym klastrze Kafka oznacza przetłumaczenie
każdego natywnego ACL na równoważne powiązanie roli — a te dwa modele nie
odwzorowują się jeden-do-jednego. Wykonywane ręcznie jest to powolne, łatwe o
subtelne pomyłki i trudne do udowodnienia jako poprawne po fakcie.

`monedula-acl-rbac-converter` czyni tę migrację mechaniczną i możliwą do przejrzenia.
Odczytuje ACL skądkolwiek się znajdują — z działającego klastra, wyeksportowanego
zrzutu `kafka-acls.sh --list`, JSON/YAML/CSV, manifestów Strimzi `KafkaUser` lub
Confluent for Kubernetes, działającego klastra Kubernetes albo starego skryptu
instalacyjnego pełnego poleceń `kafka-acls --add` — i tworzy plan powiązań ról
Confluent RBAC, w którym każdy krok jest audytowalny.

## Jak to działa

Przepływ produkcyjny jest jawny i podzielony na kroki, więc każdy etap tworzy
artefakty, które można przejrzeć, wersjonować lub dołączyć do wniosku o zmianę:

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

Wspierane są dwa modele operacyjne, w zależności od tego, jak wiele chcesz, by
narzędzie ruszało:

- **Bezpośredni (MDS)** — stosuj powiązania ról prosto w Metadata Service
  Confluent. Krok apply jest idempotentny: istniejące powiązania są pomijane.
- **Tylko artefakty** — emituj skrypty Confluent CLI, manifesty Confluent for
  Kubernetes lub polecenia `mds-curl` dla własnego potoku GitOps / kontroli zmian,
  by je zastosował, tak aby nic się nie zmieniało bez potoku, który to uruchomi.

Bezpieczeństwo jest tu sednem: plany są opatrywane sumą kontrolną, efektywny dostęp
jest weryfikowany po zastosowaniu (nowe powiązania naprawdę przyznają to, co dawały
stare ACL), a usuwanie źródłowych ACL jest oparte na skryptach — narzędzie generuje
`delete-acls.sh` oraz `rollback.sh`, dzięki czemu człowiek rozważnie przegląda i
uruchamia porządkowanie.

## Konfiguracja

Konwersję dostraja się trzema opcjonalnymi plikami YAML: `scopes.yaml` (identyfikatory
klastrów Confluent, na które nakierowane są powiązania), `rules.yaml` (niestandardowe
nadpisania mapowania) oraz `principals.yaml` (remapowanie principali). ACL typu DENY
nie mają równoważnika w RBAC, więc nie są po cichu konwertowane — są zgłaszane i
obsługiwane osobno.