Monedula
monedula-acl-rbac-converter docs menu

Two paths: with or without MDS

When to let the tool talk to Confluent MDS directly and when to emit artifacts for another team, and what each path can verify.

Concepts 1 of 4

2 min read

Updated 5 October 2026

Markdown

On this page

The first decision in a migration is whether monedula-acl-rbac itself talks to the Confluent Metadata Service (MDS), or only produces artifacts that someone else applies. Extract and plan are identical either way; the paths differ in what happens once plan.json exists, and in what the tool can check afterwards.

Path A: direct to MDS

You give the tool MDS credentials, and it creates the role bindings itself and confirms they work:

extract -> plan -> apply -> verify -> delete-acls

apply writes the bindings to MDS, and verify then checks in MDS that every source ACL’s access is granted. The tool that planned the change confirms that it landed before any ACL is deleted, and the run directory holds the evidence.

It needs MDS credentials on the host that runs the MDS commands: apply, verify, discover, mds list-bindings and auth login. Removing DENY ACLs needs them as well, because the delete-deny-acls script checks MDS again for every DENY when it runs.

Path B: no MDS access

The tool never contacts MDS. It emits an artifact for your platform team, GitOps repository or change-control pipeline to apply:

extract -> plan -> emit  (-> your CD pipeline applies it)

emit renders the plan as a Confluent CLI script, CFK ConfluentRolebinding manifests or MDS curl commands, as Hand bindings to a CD pipeline shows. convert is the one-command form of this path: it extracts, plans and emits from a file, with no run directory.

Path B fits when policy routes every MDS change through a separate pipeline, or when the credentials cannot leave the team that owns MDS. It has two costs. verify needs MDS, so the tool cannot check the result for you: confirm access another way, or run verify later from a host that has credentials. discover needs MDS too, so you fill in scopes.yaml yourself, or ask someone with access to run discover once.

Both paths end at the same gate

delete-acls requires a verify.json for the current plan and only includes ACLs whose access it confirms. On Path B, the source ACLs therefore stay until someone with MDS access has run verify, and they keep granting access in the meantime.

Rollback differs. On Path A, apply.log and plan.json record what was created, and you remove bindings yourself, as Recover from a failed run shows. On Path B, the emitted artifact is the record: keep it in your CD repository until the migration is stable, because undoing it is the inverse of applying it.