# Get Started With RBAC and Kafka Connect for Confluent Platform

RBAC uses roles and role mappings to provide different levels of access for a
principal (user or service principal) to authenticate with Connect and Kafka.

#### SEE ALSO
To get started, try the [automated RBAC example](../../security/authorization/rbac/cp-rbac-example.md#rbac-demo) that showcases the RBAC
functionality in Confluent Platform.

<a id="connect-role-mappings"></a>

## Connect Role Mappings

The table below shows the permitted Connect operations for each RBAC role.

| Roles [1]           | Register Connect Cluster   | Create Connector   | Read Connector Configuration   | Read Status   | Pause/ Restart Connector   | Scale Connector   | Configure Connector   | Manage Access   | Delete   |
|---------------------|----------------------------|--------------------|--------------------------------|---------------|----------------------------|-------------------|-----------------------|-----------------|----------|
| **SystemAdmin**     | Yes                        | Yes                | Yes                            | Yes           | Yes                        | Yes               | Yes                   | Yes             | Yes      |
| **UserAdmin**       | No                         | No                 | No                             | No            | No                         | No                | No                    | Yes             | No       |
| **ClusterAdmin**    | Yes                        | Yes                | Yes                            | Yes           | [2]                        | [2]               | No                    | Yes             | Yes      |
| **Operator**        | No                         | No                 | No                             | Yes           | Yes                        | Yes               | Yes                   | No              | No       |
| **SecurityAdmin**   | No                         | No                 | No                             | No            | No                         | No                | No                    | No              | No       |
| **ResourceOwner**   | No                         | Yes                | Yes                            | Yes           | Yes                        | Yes               | Yes                   | Yes             | Yes      |
| **DeveloperRead**   | No                         | No                 | Yes                            | Yes           | No                         | No                | No                    | No              | No       |
| **DeveloperWrite**  | No                         | No                 | No                             | Yes           | No                         | No                | Yes                   | No              | No       |
| **DeveloperManage** | No                         | Yes                | No                             | Yes           | Yes                        | Yes               | No                    | No              | No       |

**Table Notes:**

**[1]** Review the following additional information about roles:

- Each role has either a Cluster-level scope or a Resource-level scope. *Yes* means that the operation is permitted, but restricted to the role scope. See [predefined roles](../../security/authorization/rbac/rbac-predefined-roles.md#rbac-predefined-roles) for more information about role scoping.
  - Cluster-level roles: `SystemAdmin`, `UserAdmin`, `ClusterAdmin`, `Operator`, `SecurityAdmin`
  - Resource-level roles: `ResourceOwner`, `DeveloperRead`, `DeveloperWrite`, `DeveloperManage`
- Read Connector Configuration: Yes means that read-access to both the connector and task configurations is allowed.
- Read Status: Yes means that read-access is allowed for the task status.
- Scale Connector: Yes means that the role can change the number of tasks.
- Configure Connector: Yes means that the role can change any of the connector configuration parameters, *except* for `tasks.max`.
- Delete: Yes means that the role can stop and delete connectors and the Connect cluster.

**[2]** Yes; but typically this is delegated to the Operator role. <br />

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

## Connect RBAC workflow

The following is a high-level workflow for configuring RBAC for a Connect
cluster and connectors.

1. Verify that you have a role that can complete the required operations. See [confluent iam](https://docs.confluent.io/confluent-cli/current/command-reference/iam/index.html) for information about using the CLI to list and describe roles and permissions for your environment.
2. Configure RBAC for a [Connect cluster](connect-rbac-connect-cluster.md#connect-rbac-connect-cluster).
3. Configure RBAC for a [Connect worker](connect-rbac-worker.md#connect-rbac-workers).
4. Configure RBAC for a [connector](connect-rbac-connectors.md#connect-rbac-connectors).

* See the [role binding sequence](connect-rbac-example.md#connect-rbac-example-scenario) for additional details.
* To use the Connect REST API to set up role bindings, see [Configure RBAC using the REST API](../../security/authorization/rbac/rbac-config-using-rest-api.md#rbac-config-connect-using-rest-api).