.. _connect-rbac-connect-cluster: Configure |rbac| for a |kconnect| Cluster ------------------------------------------ In an |rbac|-enabled environment, you must create a |rbac-sa| for the |kconnect| cluster. Within the |rbac-sa|, you create role bindings so the |kconnect| cluster can access the |ak| cluster and other resources. Prerequisites: - The user completing this procedure must have permission to create role bindings for the |kconnect| |rbac-sa|, on the |kconnect| cluster, and on the |ak| cluster. - An installed |rbac|-enabled |cp| environment with an installed and running |ak| cluster. - The Confluent CLI installed. - Authorization to create and modify principals for the organization. .. _connect-rbac-service-account: The following steps guide you through configuring a |rbac-sa| for |kconnect-long|. How you create the |rbac-sa| 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 :ref:`rbac-get-cluster-ids`. #. Enter the following Confluent CLI command to give an example |rbac-sa| named ``$CONNECT_USER`` the role ``SecurityAdmin`` on the |kconnect| cluster. The example cluster IDs ``$CONNECT_CLUSTER`` for |kconnect| and ``$KAFKA_CLUSTER`` for |ak| are used in the command and all subsequent command examples. :: confluent iam rbac role-binding create \ --principal User:$CONNECT_USER \ --role SecurityAdmin \ --kafka-cluster-id $KAFKA_CLUSTER \ --connect-cluster-id $CONNECT_CLUSTER #. Enter the following command to give ``$CONNECT_USER`` the role ``ResourceOwner`` on the group that |kconnect| workers use to coordinate with other workers. :: confluent iam rbac role-binding create \ --principal User:$CONNECT_USER \ --role ResourceOwner \ --resource Group:$CONNECT_CLUSTER \ --kafka-cluster-id $KAFKA_CLUSTER #. Enter the following commands to give ``$CONNECT_USER`` the role ``ResourceOwner`` on the internal |ak| topics used by |kconnect| 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 |cp| to ``connect-configs``, ``connect-offsets``, and ``connect-status`` by default. :: confluent iam rbac role-binding create \ --principal User:$CONNECT_USER \ --role ResourceOwner \ --resource Topic:$CONFIGS_TOPIC \ --kafka-cluster-id $KAFKA_CLUSTER :: confluent iam rbac role-binding create \ --principal User:$CONNECT_USER \ --role ResourceOwner \ --resource Topic:$OFFSETS_TOPIC \ --kafka-cluster-id $KAFKA_CLUSTER :: confluent iam rbac role-binding create \ --principal User:$CONNECT_USER \ --role ResourceOwner \ --resource Topic:$STATUS_TOPIC \ --kafka-cluster-id $KAFKA_CLUSTER .. important:: By default the |ak| 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 |kconnect| licensing, see :connect-common:`Licensing Connectors|license.html`. .. _connect-rbac-cluster-secret-registry: If you have configured a |kconnect| :ref:`Secret Registry `, you must complete two additional steps. #. 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 |kconnect| worker properties. :: confluent iam rbac role-binding create \ --principal User:$CONNECT_USER \ --role ResourceOwner \ --resource Group:$SECRET_REGISTRY_GROUP \ --kafka-cluster-id $KAFKA_CLUSTER #. Enter the following command to give ``$CONNECT_USER`` the role ``ResourceOwner`` on the |ak| topic used to store secrets. |ak| 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 |kconnect| 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. :: confluent iam rbac role-binding create \ --principal User:$CONNECT_USER \ --role ResourceOwner \ --resource Topic:$SECRETS_TOPIC \ --kafka-cluster-id $KAFKA_CLUSTER