Example Connect role-binding sequence

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 Discover Identifiers for Clusters in Confluent Platform.

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.

   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.

   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.

   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.

   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.

   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.

   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.

7. Grant principal User:$CONNECT_USER the ResourceOwner role to Topic:_confluent-secrets.

   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.

   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.

   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.

   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-id $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-.

   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.

   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.

   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.

   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.

Tip

To use the Connect REST API to set up role bindings, see Configure RBAC using the REST API.