# Example Connect role-binding sequence for Confluent Platform The following is an example sequence for configuring RBAC role bindings when working with Kafka Connect and connectors. These tasks are completed by the RBAC system administrator. The steps assume the configuration parameters are configured as described in previous sections. In the example steps, you configure role bindings for the following principals: * Connect worker: `User:$CONNECT_USER` * Connector: `User:$CONNECTOR_USER` * User (connector creator): `User:$CLIENT` #### 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). ## Connect worker role bindings Use the following steps to configure role bindings for the Connect worker: `User:$CONNECT_USER`. 1. Grant principal `User:$CONNECT_USER` the `ResourceOwner` role for `Topic:connect-configs`. ```none confluent iam rbac role-binding create \ --principal User:$CONNECT_USER \ --role ResourceOwner \ --resource Topic:connect-configs \ --kafka-cluster $KAFKA_CLUSTER_ID ``` 2. Grant principal `User:$CONNECT_USER` the `ResourceOwner` role for `Topic:connect-offsets`. ```none confluent iam rbac role-binding create \ --principal User:$CONNECT_USER \ --role ResourceOwner \ --resource Topic:connect-offsets \ --kafka-cluster $KAFKA_CLUSTER_ID ``` 3. Grant principal `User:$CONNECT_USER` the `ResourceOwner` role for `Topic:connect-statuses`. ```none confluent iam rbac role-binding create \ --principal User:$CONNECT_USER \ --role ResourceOwner \ --resource Topic:connect-statuses \ --kafka-cluster $KAFKA_CLUSTER_ID ``` 4. Grant principal `User:$CONNECT_USER` the `ResourceOwner` role for `Group:connect-cluster`. ```none confluent iam rbac role-binding create \ --principal User:$CONNECT_USER \ --role ResourceOwner \ --resource Group:connect-cluster \ --kafka-cluster $KAFKA_CLUSTER_ID ``` 5. Grant principal `User:$CONNECT_USER` the `SecurityAdmin` role. This allows `User:$CONNECT_USER` permission to make requests to the Metadata Service (MDS) to find out if a user making calls to the Connect REST API is authorized to perform required operations. Note that `$CONNECT_USER` does this by making an authorized request to MDS to check `$CLIENT` permissions. ```none confluent iam rbac role-binding create \ --principal User:$CONNECT_USER \ --role SecurityAdmin \ --kafka-cluster $KAFKA_CLUSTER_ID \ --connect-cluster-id $CONNECT_CLUSTER_ID ``` 6. List the role bindings for the principal `User:$CONNECT_USER`. Verify that all the role bindings are properly configured. ```none confluent iam rbac role-binding list \ --principal User:$CONNECT_USER \ --kafka-cluster $KAFKA_CLUSTER_ID \ --connect-cluster-id $CONNECT_CLUSTER_ID ``` The following two steps are required if using a Connect [Secret Registry](connect-rbac-secret-registry.md#connect-rbac-secret-registry). 7. Grant principal `User:$CONNECT_USER` the `ResourceOwner` role to `Topic:_confluent-secrets`. ```none confluent iam rbac role-binding create \ --principal User:$CONNECT_USER \ --role ResourceOwner \ --resource Topic:_secrets \ --kafka-cluster $KAFKA_CLUSTER_ID ``` 8. Grant principal `User:$CONNECT_USER` the `ResourceOwner` role to `Group:secret-registry`. ```none confluent iam rbac role-binding create \ --principal User:$CONNECT_USER \ --role ResourceOwner \ --resource Group:secret-registry \ --kafka-cluster $KAFKA_CLUSTER_ID ``` ## Connector role bindings Use the following steps to configure role bindings for the connector: `User:$CONNECTOR_USER`. 1. Grant principal `User:$CONNECTOR_USER` the `ResourceOwner` role to `Topic:$DATA_TOPIC`. ```none confluent iam rbac role-binding create \ --principal User:$CONNECTOR_USER \ --role ResourceOwner \ --resource Topic:$DATA_TOPIC \ --kafka-cluster $KAFKA_CLUSTER_ID ``` The following step is only required if using **Schema Registry**. 2. Grant principal `User:$CONNECTOR_USER` the `ResourceOwner` role to `Subject:$(DATA_TOPIC)-value`. ```none confluent iam rbac role-binding create \ --principal User:$CONNECTOR_USER \ --role ResourceOwner \ --resource Subject:$(DATA_TOPIC)-value \ --kafka-cluster $KAFKA_CLUSTER_ID \ --schema-registry-cluster $SCHEMA_REGISTRY_CLUSTER_ID ``` The following step is only required for **Sink** connectors. 3. Grant principal `User:$CONNECTOR_USER` the `DeveloperRead` role to the consumer group `Group:$connect-`. ```none confluent iam rbac role-binding create \ --principal User:$CONNECTOR_USER \ --role DeveloperRead \ --resource Group:$connect- \ --prefix \ --kafka-cluster $KAFKA_CLUSTER_ID ``` 4. List the role bindings for the principal `User:$CONNECTOR_USER` to the Connect cluster. ```none confluent iam rbac role-binding list \ --principal User:$CONNECTOR_USER \ --kafka-cluster $KAFKA_CLUSTER_ID \ --connect-cluster-id $CONNECT_CLUSTER_ID ``` ## User role bindings Use the following steps to configure role bindings for the user creating and running the connector: `User:$CLIENT`. 1. Grant principal `User:$CLIENT` the `ResourceOwner` role for `Connector:$CONNECTOR_NAME`. ```none confluent iam rbac role-binding create \ --principal User:$CLIENT \ --role ResourceOwner \ --resource Connector:$CONNECTOR_NAME \ --kafka-cluster $KAFKA_CLUSTER_ID \ --connect-cluster-id $CONNECT_CLUSTER_ID ``` 2. List the role bindings for the principal `User:$CLIENT` to the Connect cluster. ```none confluent iam rbac role-binding list \ --principal User:$CLIENT \ --kafka-cluster $KAFKA_CLUSTER_ID \ --connect-cluster-id $CONNECT_CLUSTER_ID ``` After completing these steps: * The service principal for the Connect worker should have sufficient permissions and it should be possible to successfully start the worker. * The service principal for the connector in the example should have sufficient permissions to access the `$DATA_TOPIC` and Schema Registry (if applicable). * The user should have sufficient permissions to create and manage the connector in the example.