# Use Centralized ACLs with MDS for Authorization in Confluent Platform If you are using Confluent Platform RBAC-enabled Kafka clusters, then you can manage ACLs for multiple Kafka clusters using the shared, centralized MDS. This enables you to configure and store ACLs similar to the way you manage and store RBAC role bindings. ## Prerequisites Before creating and using ACLs in the centralized MDS, you must satisfy the following requirements: - You must configure RBAC on a [new Kraft-based cluster](../../../kafka/configure-mds/index.md#rbac-mds-config) (using `confluent.authorizer.access.rule.providers=CONFLUENT`). This cluster should not have any pre-existing local ACLs (e.g., those managed directly by Kafka’s native authorizer if previously enabled). You must configure MDS broker principals as `super.users` or `broker.users`. #### NOTE The `broker.users` option is a semicolon-separated list of principals of users who are allowed access to all resources on interbroker listeners. Unlike `super.users`, `broker.users` only allows requests originating from interbroker listeners. The primary purpose of this option is to bootstrap MDS clusters when configuring authorization using centralized ACLs. For details about this configuration, see [Configure Confluent Server Authorizer in Confluent Platform](../../csa-introduction.md#confluent-server-authorizer). - If you have already configured RBAC on an [existing Kraft-based cluster](enable-rbac-running-cluster.md#enable-rbac-running-cluster) that is using locally-managed ACLs (e.g., via the Kafka native authorizer), you must migrate these ACLs to centralized storage in MDS. ## Migrating ACLs to MDS The Confluent Platform [Metadata Service (MDS)](../../../kafka/configure-mds/index.md#rbac-mds-config) is a centralized service that stores ACLs and RBAC role bindings for multiple Kafka clusters. You can use the Confluent CLI to manage ACLs and RBAC role bindings for multiple Kafka clusters using the centralized MDS. You can migrate existing KRaft-based ACLs to MDS by following the steps in this section. After migration, you can add additional ACLs to MDS, which are then applied to all brokers and stored in MDS. To migrate KRaft-based ACLs to MDS, you must first enable RBAC on running clusters and configure the MDS broker principals as `super.users` or `broker.users`. Note that RBAC in KRaft mode is not supported for CFK. After enabling RBAC, brokers in your Kafka clusters can read ACLs from both their locally managed metadata and MDS. To avoid inconsistent ACLs, do not add MDS-based ACLs until after this migration is complete. To migrate the existing KRaft-based ACLs to MDS: 1. Confirm that `confluent.authorizer.access.rule.providers=CONFLUENT, KRAFT_ACL` is configured for all broker nodes and controller nodes in the `broker.properties` and `controller.properties` files, as mentioned in [Prerequisites](#acl-migration-prereqs). 2. Specify `confluent.authorizer.migrate.acls.from.cluster=true` on a single broker of choice (If the MDS cluster and Kafka cluster for which you are migrating ACLs are same, then select a broker that is not a MDS writer. You can identify the MDS writer broker in the `writerMemberId`, which is in the latest `metadata-service.log` log file). The non-MDS broker is the broker performing the KRaft ACL migration. Make note of this broker’s `broker.id`, as it is required in the next step. 3. Restart the broker which has set `confluent.authorizer.migrate.acls.from.cluster=true` as mentioned in Step 2. When restarted, this broker copies the KRaft-based ACLs to MDS and also listens for any ACL updates during migration. After completing this step, you can add additional Kafka-based ACLs, which are applied to all broker nodes and stored in the MDS. 4. After the migration completes (you can verify completion in the `kafka.authorizer.log`), verify that the centralized ACLs are in MDS using the following Confluent CLI command: ```shell confluent iam acl list --kafka-cluster ``` 5. Remove migration related flags: - Specify `confluent.authorizer.access.rule.providers=CONFLUENT` for all broker nodes and controller nodes. - Specify `confluent.authorizer.migrate.acls.from.cluster=false` for the broker from Step 2 in above section. - Perform a rolling restart of all the broker nodes in the cluster, including the broker from Step 2, which should be the last broker to be restarted. This ensures that you do not miss any ACL updates that may have occurred during migration. - Perform a rolling restart of all the controller nodes in the cluster. After completing these steps, any ACLs added directly to the Kafka cluster are ignored. Note: MDS cluster should only have `confluent.authorizer.access.rule.providers=CONFLUENT`. If MDS is currently configured with `confluent.authorizer.access.rule.providers=CONFLUENT, KRAFT_ACL`, update the MDS configuration and roll the cluster. ## Using centralized ACLs Examples in this section use the CLI [confluent iam rbac role-binding create](https://docs.confluent.io/confluent-cli/current/command-reference/iam/rbac/role-binding/confluent_iam_rbac_role-binding_create.html) command to create, delete or list ACLs. For detailed information about the supported options, run the CLI `confluent iam acl --help` command. For details about ACL format and customizing user names, see [Use Access Control Lists (ACLs) for Authorization in Confluent Platform](../acls/overview.md#kafka-authorization). ### Limitations Centralized ACLs supports up to 1000 ACLs per cluster. ### Creating centralized ACLs In this example you are creating an ACL where Principal `User:Bob` is allowed to perform a Read operation from IP 198.51.100.0 on Topic `test-topic` from a specified Kafka cluster. You can do this by running the following Confluent CLI command: ```bash confluent iam acl create --allow --principal User:Bob --operation READ --host 198.51.100.0 --topic test-topic --kafka-cluster ``` Note that `confluent iam acl` supports IPv6 addresses, but does not support IP ranges and subnets. By default all principals that don’t have an explicit ACL allowing an operation to access a resource are denied. In rare cases where an ACL that allows access to all but some principal is desired, you can use the `--deny` option. For example, use the following commands to allow all users to Read from `test-topic` in a specified Kafka cluster, but deny only `User:BadBob` from the specified Kafka cluster: ```bash confluent iam acl create --allow --principal User:'*' --operation READ --topic test-topic --kafka-cluster confluent iam acl create --deny --principal User:BadBob --operation READ --topic test-topic --kafka-cluster ``` Note that when multiple ACLs apply to a user, as shown above, the `--deny` option always overrides the `--allow` option. The preceding examples create ACLs for a topic by specifying `--topic [topic-name]` as the resource pattern option. Similarly, you can create ACLs for a cluster by specifying `--cluster-scope` and to a group by specifying `--group:[group-name]`. In the event that you want to grant permission to all groups, you can do so by specifying `--group='*'` as shown in the following Confluent CLI command: ```bash confluent iam acl create --allow --principal User:'*' --operation READ --topic test --group='*' --kafka-cluster ``` You can add ACLs on prefixed resource patterns too. For example, if you include `--topic abc-` and `--prefix` in the command, it will impact permissions on all resources whose name starts with `abc-`. The next example shows how to add an ACL for user Jane to access any topic whose name starts with `test-` in a specified Kafka cluster. You can do this by running the following Confluent CLI command, with following options: ```bash confluent iam acl create --allow --principal User:Jane --prefix --topic test- --kafka-cluster ``` ### Deleting centralized ACLs To delete the ACL added in the first example above, run the following Confluent CLI command: ```bash confluent iam acl delete --allow --principal User:Bob --operation READ --host 198.51.100.0 --topic test-topic --kafka-cluster ``` If you want to remove the ACL that you created using a prefixed pattern, run the following Confluent CLI command: ```bash confluent iam acl create --allow --principal User:Jane --prefix --topic test-topic --kafka-cluster ``` ### Listing centralized ACLs You can list the ACLs for a given Kafka cluster using the Confluent CLI `confluent iam acl list` command and the cluster ID. For example, to list all ACLs for `test-topic` that use the prefix `test-` in a specified Kafka cluster, execute the following: ```bash confluent iam acl list --topic test-topic --prefix --kafka-cluster ``` Note that this will only return the ACLs that have been added to this exact prefix pattern.