<a id="rbac-cli-quickstart"></a>

# Role-Based Access Control for Confluent Platform Quick Start

Role-based access control (RBAC) is administered by a [super user](../acls/overview.md#kafka-authorization)
using the Confluent CLI and distributed across an organization. This quick start
demonstrates how to create roles and interact with Kafka topics in an RBAC
environment.

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

Prerequisites
: - [Confluent Platform](../../../installation/index.md#installation-overview).
  - Confluent CLI (included with Confluent Platform since 5.4.x).
  - The Confluent Platform commercial component `confluent-server`. For more information, see
    [Migrate Confluent Platform to Confluent Server](../../../installation/migrate-confluent-server.md#migrate-confluent-server).
  - An RBAC-enabled cluster that you have super user access to, or the SystemAdmin
    role. For more information, see [Use Predefined RBAC Roles in Confluent Platform](rbac-predefined-roles.md#rbac-predefined-roles).

## Sign in to cluster

1. Sign in to the Confluent CLI with the RBAC Metadata Service (MDS) URL (`<url>`) specified.
   For more information, see [confluent login](https://docs.confluent.io/confluent-cli/current/command-reference/confluent_login.html)
   .
   ```none
   confluent login --url <url>
   ```
2. Specify the super user credentials when prompted.

   #### IMPORTANT
   The user ID specified in group role bindings is case-specific, and must match
   the case specified in the AD record. Also note that when logging in as a super user,
   the login ID is also case-specific and must match the case specified for the user
   ID in role bindings.

   ```none
   Enter your Confluent credentials:
   Username:
   Password:
   ```

   Your output should resemble:
   ```none
   Logged in as user
   ```

<a id="rbac-rolebinding-sysadmin-role"></a>

## Grant the SystemAdmin role

The user you are creating role bindings for (`my-user-name`) must be created
in LDAP before you can actually log in with this user to the system.

#### NOTE
Confluent Platform cluster registry provides a way for Kafka cluster administrators to centrally
register Kafka clusters in the metadata service (MDS) to enable a more
user-friendly RBAC role binding experience. For details, refer to
[Cluster Registry in Confluent Platform](../../cluster-registry.md#cluster-registry).

#### IMPORTANT
The user ID specified in group role bindings is case-specific, and must match
the case specified in the AD record. Also note that when logging in as a super user,
the login ID is also case-specific and must match the case specified for the user
ID in role bindings.

1. Grant the [SystemAdmin role](rbac-predefined-roles.md#rbac-predefined-roles) (`SystemAdmin`)
   to a user (`<my-user-name>`)  on the Kafka cluster (`<kafka-cluster-id>`).
   For more information, see [confluent iam rbac role-binding create](https://docs.confluent.io/confluent-cli/current/command-reference/iam/rbac/role-binding/confluent_iam_rbac_role-binding_create.html).
   ```none
   confluent iam rbac role-binding create \
   --principal User:<my-user-name> \
   --role SystemAdmin \
   --kafka-cluster <kafka-cluster-id>
   ```
2. Grant [SystemAdmin role](rbac-predefined-roles.md#rbac-predefined-roles) for the Confluent Platform components
   to a user.
   - Confluent Control Center
     ```none
     confluent iam rbac role-binding create \
     --principal User:<my-user-name> \
     --role SystemAdmin \
     --kafka-cluster <kafka-cluster-id>
     ```
   - Connect
     ```none
     confluent iam rbac role-binding create \
     --principal User:<my-user-name> \
     --role SystemAdmin \
     --kafka-cluster <kafka-cluster-id> \
     --connect-cluster-id <connect-cluster-id>
     ```
   - ksqlDB
     ```none
     confluent iam rbac role-binding create \
     --principal User:<my-user-name> \
     --role SystemAdmin \
     --kafka-cluster <kafka-cluster-id> \
     --ksql-cluster-id <ksql-cluster-id>
     ```
   - Schema Registry
     ```none
     confluent iam rbac role-binding create \
     --principal User:<my-user-name> \
     --role SystemAdmin \
     --kafka-cluster <kafka-cluster-id> \
     --schema-registry-cluster <schema-registry-cluster-id>
     ```
   - Confluent Platform for Apache Flink
     ```none
     confluent iam rbac role-binding create \
     --principal User:u-developer \
     --role SystemAdmin \
     --cmf CMF-id
     ```

   If the cluster you are referencing is defined in the
   [cluster registry](../../cluster-registry.md#cluster-registry), you can specify the
   role binding using the cluster name only (without the cluster ID) as follows:
   ```none
   confluent iam rbac role-binding create \
   --principal User:<my-user-name> \
   --role SystemAdmin \
   --cluster-name <exampleConnect>
   ```

## Grant the UserAdmin role on the Kafka cluster

The [UserAdmin role](rbac-predefined-roles.md#rbac-predefined-roles) grants the user permission to
manage permissions for other users. This command grants UserAdmin to a user.

```none
confluent iam rbac role-binding create \
--principal User:<my-user-name> \
--role UserAdmin \
--kafka-cluster <kafka-cluster-id>
```

<a id="grant-topic-perms"></a>

## Grant topic permissions

To interact with topics using the [Kafka CLI tools](../../../tools/cli-reference.md#cp-all-cli), you must
provide a JAAS configuration that enables Kafka CLI tools to authenticate with a broker.
You can provide the JAAS configuration using a file (`--command-config`) or using the
command line options `--producer-property` or `--consumer-property` for the producer or
consumer. This configuration is required for creating topics, producing, consuming,
and more. For example:

```none
kafka-console-producer --producer-property sasl.mechanism=OAUTHBEARER
```

The value you specify in `sasl.mechanism` depends on your broker’s security
configuration for the port. In this case, OAUTHBEARER is used because it is the
default configuration in the automated RBAC demo. However, you can use any
authentication mechanism exposed by your broker.

#### IMPORTANT
For custom Kafka clients (Java or librdkafka), do not use the RBAC token
listener for external client communications. Dependencies required for
this authentication are not included in the Kafka client libraries. With
RBAC enabled, token services are intended for internal communication
between Confluent Platform components only (for example, it is valid for a Schema Registry licensed
client), and not for long-running service principals or client authentication.
For long-lived or client use cases, Use one of the supported authentication
methods, like SASL or mTLS (mutual TLS). For details, see
[Authentication Methods Overview](../../authentication/overview.md#authentication-overview).

To identify which roles provide write access to a topic, see [Predefined roles](rbac-predefined-roles.md#rbac-predefined-roles).

1. Create a configuration file named `my-user-name.properties`, and specify the MDS service
   (`<metadata_server_urls>`), username (`<my-user-name>`), and password (`<my-password>`).
   You can also specify these same properties using the command line.
   ```none
   sasl.mechanism=OAUTHBEARER
   # Use SASL_SSL for production environments
   security.protocol=SASL_PLAINTEXT
   sasl.login.callback.handler.class=io.confluent.kafka.clients.plugins.auth.token.TokenUserLoginCallbackHandler
   sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
   username="<my-user-name>" \
   password="<my-password>" \
   metadataServerUrls="<metadata_server_urls>";
   ```
2. Grant a user permissions to a topic (`<topic-name>`). For example, you can
   grant topic permissions to ResourceOwner or DeveloperManage roles on the resource level;
   or to the SystemAdmin role at the cluster level. To create a topic, the
   DeveloperManage role is required on the topic resource. Other [roles](rbac-predefined-roles.md#rbac-predefined-roles) that grant
   the ability to create topics are ResourceOwner on the topic resource, or SystemAdmin
   at the cluster level.
   ```none
   confluent iam rbac role-binding create \
   --principal User:<my-user-name> \
   --role ResourceOwner \
   --resource Topic:test-topic- \
   --prefix \
   --kafka-cluster <kafka-cluster-id>
   ```
3. Create a topic using the Kafka kafka-topics tool found in the `bin` directory with the `my-user-name.properties` specified.
   ```none
   kafka-topics \
   --bootstrap-server <kafka-hostname>:9092 \
   --command-config ~/my-user-name.properties \
   --topic test-topic-1 \
   --create \
   --replication-factor 1 \
   --partitions 3
   ```

## Produce to a topic

To produce to a topic, you must have (minimally) DeveloperWrite role for that topic.
You are not required to be an owner of the topic to produce to it.

1. Grant the user permissions to access the topic. Use DeveloperWrite role on
   the topic resource.
   ```none
   confluent iam rbac role-binding create \
   --principal User:<my-producer-user> \
   --role DeveloperWrite \
   --resource Topic:test-topic- \
   --prefix \
   --kafka-cluster <kafka-cluster-id>
   ```
2. Produce to a topic using the kafka-console-producer tool.
   ```none
   echo "test_message" | ./kafka-console-producer \
   --broker-list <kafka-hostname>:9092 \
   --topic test-topic-1 \
   --producer.config ~/my-producer-user.properties \
   --property parse.key=false
   ```

Any principal used by Idempotent producers must be granted IdempotentWrite
on the cluster or Write permission on any topic to initialize the producer client.
Binding either the DeveloperWrite or ResourceOwner RBAC roles on the Kafka
cluster grants Write permission. Note that DeveloperWrite is the less
permissive of the two roles, and is the first recommendation. The following
role binding ensures that Write has access to the cluster:

```none
confluent iam rbac role-binding create \
   --principal $PRINCIPAL \
   --role DeveloperWrite \
   --resource Cluster:kafka-cluster \
   $KAFKA_CLUSTER_ID
```

The previous example only grants the IdempotentWrite operation, which is a
non-destructive operation.

## Consume from a topic

To consume from a topic, you must have DeveloperRead access to both the topic
resource and consumer group resource. If users require the ability to delete
consumer groups, then also assign the ResourceOwner role on the consumer group
prefix. Note that consume does not require additional Kafka permissions to be
Idempotent consumers (as producers do).

To grant the required permissions, run the following commands:

1. Grant permission to topic resource.
   ```none
   confluent iam rbac role-binding create \
   --principal User:<my-consumer-user> \
   --role DeveloperRead \
   --resource Topic:test-topic- \
   --prefix \
   --kafka-cluster <kafka-cluster-id>
   ```
2. Grant permission to the consumer group.

   To consume from a topic as a member of a consumer group, you must have access
   to the topic resource and consumer group resource. Grant the DeveloperRead role
   to the topic resource and consumer group resource. As mentioned in the previous
   step, assign the ResourceOwner role only if users require the ability to delete
   consumer groups.
   ```none
   confluent iam rbac role-binding create \
   --principal User:my-consumer-user \
   --role DeveloperRead \
   --resource Group:console-consumer- \
   --prefix \
   --kafka-cluster <kafka-cluster-id>
   ```
3. Consume using the kafka-console-consumer tool.
   ```none
   ./kafka-console-consumer \
   --bootstrap-server <kafka-hostname>:9092 \
   --topic test-topic-1 \
   --consumer.config ~/my-consumer-user.properties \
   --from-beginning \
   --property parse.key=false
   ```

## Related Content

- [How to enable DEBUG Logging for Metadata Service (MDS) or RBAC](https://support.confluent.io/hc/en-us/articles/360040012511) (Confluent Support)
