.. _connect-rbac-example-scenario: Example |kconnect| role-binding sequence ---------------------------------------- The following is an example sequence for configuring RBAC role bindings when working with |kconnect-long| 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: * |kconnect| worker: ``User:$CONNECT_USER`` * Connector: ``User:$CONNECTOR_USER`` * User (connector creator): ``User:$CLIENT`` .. note:: For instructions on getting your actual cluster IDs, refer to :ref:`rbac-get-cluster-ids`. ------------------------------- |kconnect| worker role bindings ------------------------------- Use the following steps to configure role bindings for the |kconnect| worker: ``User:$CONNECT_USER``. #. 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-id $KAFKA_CLUSTER_ID #. 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-id $KAFKA_CLUSTER_ID #. 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-id $KAFKA_CLUSTER_ID #. 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-id $KAFKA_CLUSTER_ID #. 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 |kconnect| 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-id $KAFKA_CLUSTER_ID \ --connect-cluster-id $CONNECT_CLUSTER_ID #. 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-id $KAFKA_CLUSTER_ID \ --connect-cluster-id $CONNECT_CLUSTER_ID The following two steps are required if using a |kconnect| :ref:`Secret Registry `. #. 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-id $KAFKA_CLUSTER_ID #. 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-id $KAFKA_CLUSTER_ID ----------------------- Connector role bindings ----------------------- Use the following steps to configure role bindings for the connector: ``User:$CONNECTOR_USER``. #. 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-id $KAFKA_CLUSTER_ID The following step is only required if using **Schema Registry**. #. 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-id $KAFKA_CLUSTER_ID \ --schema-registry-cluster-id $SCHEMA_REGISTRY_CLUSTER_ID The following step is only required for **Sink** connectors. #. 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-id $KAFKA_CLUSTER_ID #. List the role bindings for the principal ``User:$CONNECTOR_USER`` to the |kconnect| cluster. :: confluent iam rbac role-binding list \ --principal User:$CONNECTOR_USER \ --kafka-cluster-id $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``. #. 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-id $KAFKA_CLUSTER_ID \ --connect-cluster-id $CONNECT_CLUSTER_ID #. List the role bindings for the principal ``User:$CLIENT`` to the |kconnect| cluster. :: confluent iam rbac role-binding list \ --principal User:$CLIENT \ --kafka-cluster-id $KAFKA_CLUSTER_ID \ --connect-cluster-id $CONNECT_CLUSTER_ID After completing these steps: * The |rbac-sa| for the |kconnect| worker should have sufficient permissions and it should be possible to successfully start the worker. * The |rbac-sa| for the connector in the example should have sufficient permissions to access the ``$DATA_TOPIC`` and |sr| (if applicable). * The user should have sufficient permissions to create and manage the connector in the example. .. tip:: To use the |kconnect| REST API to set up role bindings, see :ref:`Configure RBAC using the REST API `.