---
title: "Two paths: with or without MDS"
description: "When to let the tool talk to Confluent MDS directly and when to emit artifacts for another team, and what each path can verify."
url: https://monedula.dev/flock/docs/acl-rbac-converter/concepts/two-paths/
---
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:

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

`apply` writes the bindings to MDS, and [`verify`](/flock/docs/acl-rbac-converter/how-to/verify-effective-access/) 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:

```text
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](/flock/docs/acl-rbac-converter/how-to/emit-for-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](/flock/docs/acl-rbac-converter/how-to/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.

## Related

- [Apply role bindings to MDS](/flock/docs/acl-rbac-converter/how-to/apply-to-mds/) is the recipe for Path A.
- [Find the cluster IDs for scopes.yaml](/flock/docs/acl-rbac-converter/how-to/find-cluster-ids/) covers both ways of filling in `scopes.yaml`.
- [Your first ACL to RBAC migration](/flock/docs/acl-rbac-converter/tutorials/first-migration/) walks Path A end to end.