---
title: "Find the cluster IDs for scopes.yaml"
description: "Get the Kafka, Schema Registry, ksqlDB and Connect cluster IDs that scope every role binding, with or without access to MDS."
url: https://monedula.dev/flock/docs/acl-rbac-converter/how-to/find-cluster-ids/
---
Every Confluent role binding is scoped to a cluster, so `plan` needs `scopes.yaml` with the IDs of the clusters your bindings target. For most migrations that is one value, `kafka_cluster`: the ID that MDS knows your Kafka cluster by.

## Ask MDS, if you have access

`discover` queries MDS for the clusters it knows and writes a `scopes.yaml` stub:

```bash
monedula-acl-rbac discover --mds-url https://mds.example.com > scopes.yaml
```

It takes the same MDS flags as [`apply`](/flock/docs/acl-rbac-converter/how-to/apply-to-mds/). The stub sets `kafka_cluster` to the first Kafka cluster MDS reports and lists any others in a comment. It fills in the Schema Registry, ksqlDB and Connect cluster IDs when MDS reports them, and leaves comments for the fields you may need to complete by hand. `discover` reads the cluster registry at `/security/1.0/registry/clusters`, so you can also query that endpoint yourself.

## Read the ID from the cluster, without MDS

- **Self-managed Confluent Platform**: the ID is a base64 cluster UUID, for example `MkU3OEVBNTcwNTJENDM2Qk`. Read it from the `meta.properties` file in any broker's log directory:

  ```bash
  grep cluster.id <log.dir>/meta.properties
  ```

  Or ask a broker: `kafka-cluster cluster-id --bootstrap-server <host:port>` prints it. MDS learns the ID from the broker's own `cluster.id`, so this is the value MDS uses.
- **Confluent Cloud**: the logical cluster ID, which starts with `lkc-`, from the Cloud Console or `confluent kafka cluster list`.

## Write scopes.yaml

Put the IDs in `scopes.yaml`. A Kafka-only migration needs one line:

```yaml
kafka_cluster: MkU3OEVBNTcwNTJENDM2Qk
```

Add `schema_registry_cluster` when your ACLs cover Schema Registry subjects. The file also accepts `ksql_cluster` and `connect_cluster`, which `discover` fills in, but `plan` requires neither: the ACL resource types the tool reads include no ksqlDB or Connect resources. [Config files](/flock/docs/acl-rbac-converter/reference/config-files/) lists every field of `scopes.yaml`.

<Callout type="warning" title="The ID must match exactly">
A `kafka_cluster` value that differs from the ID MDS knows the cluster by produces bindings that apply without error and grant no access. `verify` reports those ACLs as `EFFECTIVE_MISSING`, and `delete-acls` will not delete them.
</Callout>

## Check it worked

Run `plan` with the file: when a binding needs a cluster ID that `scopes.yaml` does not have, `plan` stops with an error that names the missing field. After `apply`, if `verify` reports `EFFECTIVE_MISSING` for all the source ACLs, check the cluster ID first.

## Related

- [Plan and review role bindings](/flock/docs/acl-rbac-converter/how-to/plan-and-review/) uses `scopes.yaml`.
- The [discover command reference](/flock/docs/acl-rbac-converter/reference/cli/discover/) lists its flags.
- Runnable version: [live-mds-migration](https://github.com/monedula-dev/monedula-acl-rbac-converter/tree/main/examples/live-mds-migration), whose pipeline derives `scopes.yaml` from MDS at run time.