<a id="connect-rbac-connect-cluster"></a>

# Configure RBAC for a Connect Cluster for Confluent Platform

In an RBAC-enabled environment, you must create a service principal for the Connect
cluster. Within the service principal, you create role bindings so the Connect
cluster can access the Kafka cluster and other resources.

Prerequisites:
: - The user completing this procedure must have permission to create role bindings for the Connect service principal, on the Connect cluster, and on the Kafka cluster.
  - An installed RBAC-enabled Confluent Platform environment with an installed and running Kafka cluster.
  - The Confluent CLI installed.
  - Authorization to create and modify principals for the organization.

<a id="connect-rbac-service-account"></a>

The following steps guide you through configuring a service principal for
Kafka Connect. How you create the service principal depends on your organization
and operating environment (on-premises, private cloud, or public cloud) and is
not covered in this procedure.

#### NOTE
For instructions on getting your actual cluster IDs, refer to
[Cluster Identifiers in Confluent Platform](../../security/authorization/rbac/rbac-get-cluster-ids.md#rbac-get-cluster-ids).

1. Enter the following Confluent CLI command to give an example service principal named `$CONNECT_USER` the role `SecurityAdmin` on the Connect cluster. The example cluster IDs `$CONNECT_CLUSTER` for Connect and `$KAFKA_CLUSTER` for Kafka are used in the command and all subsequent command examples.
   ```none
   confluent iam rbac role-binding create \
   --principal User:$CONNECT_USER \
   --role SecurityAdmin \
   --kafka-cluster $KAFKA_CLUSTER \
   --connect-cluster-id $CONNECT_CLUSTER
   ```
2. Enter the following command to give `$CONNECT_USER` the role `ResourceOwner` on the group that Connect workers use to coordinate with other workers.
   ```none
   confluent iam rbac role-binding create \
   --principal User:$CONNECT_USER \
   --role ResourceOwner \
   --resource Group:$CONNECT_CLUSTER \
   --kafka-cluster $KAFKA_CLUSTER
   ```
3. Enter the following commands to give `$CONNECT_USER` the role `ResourceOwner` on the internal Kafka topics used by Connect to store configuration, status, and offset information. Internal configuration topic `$CONFIGS_TOPIC`, internal offsets topic `$OFFSETS_TOPIC`, and status topic `$STATUS_TOPIC` are used in the examples.

   #### NOTE
   The configuration topics `config.storage.topic`,
   `offset.storage.topic`, and `status.storage.topic` are where the
   internal configuration, offset configuration, and status configuration
   data are stored. These are set for Confluent Platform to `connect-configs`,
   `connect-offsets`, and `connect-status` by default.

   ```none
   confluent iam rbac role-binding create \
   --principal User:$CONNECT_USER \
   --role ResourceOwner \
   --resource Topic:$CONFIGS_TOPIC \
   --kafka-cluster $KAFKA_CLUSTER
   ```

   ```none
   confluent iam rbac role-binding create \
   --principal User:$CONNECT_USER \
   --role ResourceOwner \
   --resource Topic:$OFFSETS_TOPIC \
   --kafka-cluster $KAFKA_CLUSTER
   ```

   ```none
   confluent iam rbac role-binding create \
   --principal User:$CONNECT_USER \
   --role ResourceOwner \
   --resource Topic:$STATUS_TOPIC \
   --kafka-cluster $KAFKA_CLUSTER
   ```

   #### IMPORTANT
   By default the Kafka worker uses the same settings and the same principal
   for reading and writing to the `_confluent-command` license topic that
   it uses to read and write to internal topics. For more information about
   Connect licensing, see [Licensing Connectors](/kafka-connectors/self-managed/license.html).

<a id="connect-rbac-cluster-secret-registry"></a>

If you have configured a Connect [Secret Registry](connect-rbac-secret-registry.md#connect-rbac-secret-registry), you must complete two additional steps.

1. Enter the following command to give `$CONNECT_USER` the role `ResourceOwner` on the group that secret registry nodes use to coordinate with other nodes. Secret Registry group ID `$SECRET_REGISTRY_GROUP` is used in the example. Note that the actual value of `$SECRET_REGISTRY_GROUP` needs to match the value of `config.providers.secret.param.secret.registry.group.id` in the Connect worker properties. This value defaults to `secret-registry` if not specified in the Connect worker properties.
   ```none
   confluent iam rbac role-binding create \
   --principal User:$CONNECT_USER \
   --role ResourceOwner \
   --resource Group:$SECRET_REGISTRY_GROUP \
   --kafka-cluster $KAFKA_CLUSTER
   ```
2. Enter the following command to give `$CONNECT_USER` the role `ResourceOwner` on the Kafka topic used to store secrets. Kafka secrets topic `$SECRETS_TOPIC` is used in the example. Note that the actual value of `$SECRETS_TOPIC` needs to match the value of `config.providers.secret.param.kafkastore.topic` in the Connect worker properties. This value defaults to `_confluent-secrets` if not specified in the Connect worker properties.

   #### WARNING
   The default value for the secrets topic changed from `_secrets` to `_confluent-secrets` in version 5.4. If your Secret Registry cluster is not configured with a `kafkastore.topic` property, explicitly set it to `_secrets` before upgrading to 5.4, to avoid losing existing secrets.

   ```none
   confluent iam rbac role-binding create \
   --principal User:$CONNECT_USER \
   --role ResourceOwner \
   --resource Topic:$SECRETS_TOPIC \
   --kafka-cluster $KAFKA_CLUSTER
   ```