.. title:: Deploy Secure ksqlDB with RBAC in Confluent Platform .. meta:: :description: Grant role-based permissions for ksqlDB to access Kafka cluster resources. .. _ksql-rbac: Deploy Secure |ksqldb| with RBAC in |cp| ######################################## Starting in |cp| 5.3, |ksqldb| supports :ref:`role-based access control (RBAC) ` to cluster resources. .. note:: |ksqldb| supports |rbac| to provide authorization to |ksqldb| clusters when running in interactive mode. |rbac| for users isn't used in |ksqldb| clusters that are deployed in headless mode. Use the :confluent-cli:`Confluent CLI|command-reference/iam/rbac/role-binding/confluent_iam_rbac_role-binding_create.html` or :ref:`Control Center ` to create roles for users. You need the cluster ID of the |ak| cluster, the service ID of the |ksqldb| cluster, and the cluster ID of the |sr| cluster, if your topics have Avro, Protobuf, or JSON_SR schemas. For more information, see :ref:`rbac-get-cluster-ids`. .. include:: ../../includes/rbac-demo.rst |ksqldb| |rbac-sa| ****************** |ksqldb| applications run with the roles granted to a privileged *ksqlDB user* |rbac-sa|. By default, the |ksqldb| |rbac-sa| is named "ksql". The roles granted to the |ksqldb| |rbac-sa| by default are required to run |ksqldb| and are distinct from the roles granted to an interactive user who wants to connect and contribute to |ksqldb|. When you grant roles to an interactive user, you must also grant the same roles to the |ksqldb| user |rbac-sa|. |ksqldb| applications execute user commands as the |ksqldb| |rbac-sa| in the background and on other servers in the |ksqldb| cluster, and some |ksqldb| statements start long-running persistent queries. |ksqldb| checks that the interactive user has the required permissions to access any resources required, but the query itself runs in the security context of the |ksqldb| |rbac-sa|. For this reason, it's important that both the interactive user and the |ksqldb| |rbac-sa| have the correct permissions to all resources required by any |ksqldb| statements. The following example commands show how to grant an interactive user and the |ksqldb| |rbac-sa| read-only access to a topic. To grant these roles, you must be logged in to the |confluent-cli| with sufficient permissions, for example as ``UserAdmin`` or ``ResourceOwner``. .. code:: bash # Grant read-only access for a user to a topic. confluent iam rbac role-binding create \ --principal User: \ --role DeveloperRead \ --resource Topic: \ --kafka-cluster-id # Grant read-only access for the ksql service principal to a topic. confluent iam rbac role-binding create \ --principal User:ksql \ --role DeveloperRead \ --resource Topic: \ --kafka-cluster-id Configure |ksqldb| Server for |rbac| ************************************ Assign the following configuration settings in the |ksqldb| Server properties file to enable |ksqldb| in an :ref:`RBAC environment `. To access the Confluent security service, you must generate a public/private key pair. Specify the path to the public key file by assigning the ``public.key.path`` setting. For more information, see :ref:`rbac-mds-config`. .. include:: ../../includes/secret-tip.rst Append the following settings to the |ksqldb| Server configuration file, which by default is named ``${CONFLUENT_HOME}/etc/ksqldb/ksql-server.properties``. .. code:: properties #------ External service configuration ------- # The set of Kafka brokers to bootstrap Kafka cluster information from bootstrap.servers=:9092 # Schema Registry authentication ksql.schema.registry.url=http://:8081 # Credentials for accessing Schema Registry ksql.schema.registry.basic.auth.user.info=: ############ ksqlDB security settings for Confluent RBAC ###################### # Set the ksqlDB cluster ID to work on specific roles and permissions for this ksqlDB cluster scope. ksql.service.id= # Enable the ksqlDB Confluent security plugin. ksql.security.extension.class=io.confluent.ksql.security.KsqlConfluentSecurityExtension # Enable permissions validations used for persistent queries requests. # By default, this setting is set to 'auto', but DESCRIBE_CONFIGS ACLs on the Kafka cluster are required for the client user. ksql.access.validator.enable=on # Assign the metadata URL and access credentials, which are shared by authentication security handlers and the ksqlDB security extension. # May be the same as the Kafka cluster hostname. confluent.metadata.bootstrap.server.urls=http://:8090 confluent.metadata.http.auth.credentials.provider=BASIC # Credentials for accessing the metadata server confluent.metadata.basic.auth.user.info=: # Enable ksqlDB Basic+Bearer authentication. ksql.authentication.plugin.class=io.confluent.ksql.security.VertxBearerOrBasicAuthenticationPlugin # Assign credentials for Kafka access. # These settings may vary, depending on your Kafka cluster authentication settings. security.protocol=SASL_PLAINTEXT sasl.mechanism=OAUTHBEARER sasl.login.callback.handler.class=io.confluent.kafka.clients.plugins.auth.token.TokenUserLoginCallbackHandler # Credentials for the ksqlDB user, which has the default user name of "ksql". # These credentials authorize ksqlDB Server to access the Kafka cluster. sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \ metadataServerUrls="http://" username="" password=""; Save the file and restart |ksqldb| Server. Log in to the server by using the |ksqldb| CLI. .. code:: bash ksql --config-file https://: --user --password |rbac| for |ksqldb| depends on the |cp| :ref:`Metadata Service (MDS) ` and the |csa|. The ``confluent.metadata`` settings configure the Metadata Service. The ``ksql.security.extension.class`` setting configures |ksqldb| for the |csa|. For more information, see :ref:`confluent_server_authorizer`. Use the |ksqldb| |rbac-sa| credentials for the following settings. - ``sasl.jaas.config`` for authorizing to the Kafka cluster with |csa| - ``confluent.metadata.basic.auth.user.info`` for authorizing to MDS - ``ksql.schema.registry.basic.auth.user.info`` for authorizing to |sr| .. note:: When RBAC is enabled and the |sr| ``/permissions`` endpoint is reachable, |ksqldb| checks whether SQL statements have permissions to access |sr| schemas. The ``ksql.security.extension.sr-permissions.validator.enabled`` config controls whether this check occurs. The default is ``true``. For additional configurations available to any client communicating with MDS, see :ref:`rest-client-mds-config` in the |cp| Security documentation. Assign roles for |ksqldb| access ******************************** The following section defines the minimal set of roles and resources required for a user to connect to |ksqldb| and execute SQL statements, including transient queries. As a best practice for security, give users the minimum necessary access level to resources. For example, prefer granting an interactive user the ``DeveloperRead`` role over the ``ResourceOwner`` role for reading from a topic. .. important:: Users require permissions in Kafka to use any |ksqldb| statements that attempt to read, write, list, and create topics. Additional access to resources on the Kafka cluster and |sr| must be granted explicitly. For more information, see :ref:`config-security-ksql-grant-access`. To grant these roles, you must be logged in to the |confluent-cli| as a ``UserAdmin``, ``ResourceOwner``, or other role with sufficient permissions. |ksqldb| role mappings ====================== The following table shows the permitted |ksqldb| operations for each RBAC role. ================ ========================= ============================ ================================== =================================== Role Access a |ksqldb| cluster Terminate a |ksqldb| cluster Modify access to |ksqldb| clusters View access from a |ksqldb| cluster ================ ========================= ============================ ================================== =================================== SystemAdmin Yes Yes Yes Yes UserAdmin No No Yes Yes ClusterAdmin Yes Yes No No Operator No No No No SecurityAdmin No No No Yes ResourceOwner Yes Yes Yes No DeveloperRead No No No No DeveloperWrite Yes No No No DeveloperManage No Yes No No ================ ========================= ============================ ================================== =================================== Cluster identifiers =================== To create role bindings, you need the cluster identifiers for the components in your |cp| deployment. For more information, see :ref:`rbac-get-cluster-ids`. The following commands use these environment variables for the cluster IDs. Variables for the interactive user name and topic name are also defined. .. code:: bash # Cluster identifiers export KAFKA_ID= export KSQLDB_ID= export SR_ID= # The name of the interactive user and # the name of a topic for the user to access. export USER_NAME= export TOPIC_NAME= .. _ksql-rbac-register-cluster: Use a registered cluster name ============================= You can register your |ksqldb| cluster and specify a user-friendly cluster name, which enables creating role bindings more easily. In all of the following example commands, you can use the cluster name instead of $KAFKA_ID and $KSQLDB_ID. For more information, see :ref:`cluster-registry`. For example, you can update the following command: .. sourcecode:: bash :emphasize-lines: 4,5 confluent iam rbac role-binding create \ --principal User: \ --role ResourceOwner \ --kafka-cluster-id $KAFKA_ID \ --ksql-cluster-id $KSQLDB_ID \ --resource KsqlCluster:ksql-cluster Assuming your |ksqldb| cluster has been registered in cluster registry with $KAFKA_ID and $KSQLDB_ID, you can use the user-friendly name instead of the IDs. Update the previous command by using the registered cluster name, which in this example is ````: .. sourcecode:: bash :emphasize-lines: 4 confluent iam rbac role-binding create \ --principal User: \ --role ResourceOwner \ --cluster-name --resource KsqlCluster:ksql-cluster .. _ksql-rbac-assign-startup-roles: Assign roles for starting |ksqldb| Server ========================================= To start |ksqldb| Server and connect to a secured Kafka cluster, a user must have the following roles granted by a ``UserAdmin``. |ksqldb| cluster scope ---------------------- Run the following commands to assign the ``ResourceOwner`` role on the |ksqldb| cluster, which binds ownership of the |ksqldb| cluster's resources to the user. A user who has the ``ResourceOwner`` or ``ClusterAdmin`` role on a |ksqldb| cluster is a *cluster owner*. .. code:: bash confluent iam rbac role-binding create \ --principal User: \ --role ResourceOwner \ --kafka-cluster-id $KAFKA_ID \ --ksql-cluster-id $KSQLDB_ID \ --resource KsqlCluster:ksql-cluster confluent iam rbac role-binding create \ --principal User: \ --role SecurityAdmin \ --kafka-cluster-id $KAFKA_CLUSTER_ID \ --ksql-cluster-id $KSQLDB_ID Run the following command to assign the ``ResourceOwner`` role to the |ksqldb| |rbac-sa|. .. code:: bash confluent iam rbac role-binding create \ --principal User:ksql \ --role ResourceOwner \ --kafka-cluster-id $KAFKA_ID \ --ksql-cluster-id $KSQLDB_ID \ --resource KsqlCluster:ksql-cluster Kafka cluster scope ------------------- Grant the ``ResourceOwner`` role to the |ksqldb| |rbac-sa| on the following internal |ksqldb| resources. By default, these roles are granted to the |ksqldb| user named "ksql". - |ksqldb| command topic: ``_confluent-ksql-${KSQLDB_ID}_command_topic`` - |ksqldb| processing log topic: ``${KSQLDB_ID}ksql_processing_log`` - Consumer groups: Prefixed with ``_confluent-ksql-${KSQLDB_ID}`` .. important:: Only grant access to the |ksqldb| command topic *for accounts that have administrator roles*. Granting access to non-admin accounts can result in a lower-privileged RBAC user being able to escalate privileges to a ``ClusterAdmin``-like level on the associated |ksqldb| cluster within the same Organization boundary. Also, grant the ``DeveloperWrite`` role to the |ksqldb| |rbac-sa| on the ``Transactional-Id`` resource. - ``Transactional-Id`` resource: ``--resource Transactional-Id:${KSQLDB_ID}`` Use the following command to grant full access for the |ksqldb| |rbac-sa| to the |ksqldb| command topic. .. code:: bash # Grant full access for the ksql service principal to the ksqlDB command topic. confluent iam rbac role-binding create \ --principal User:ksql \ --role ResourceOwner \ --resource Topic:_confluent-ksql-${KSQLDB_ID}_command_topic \ --kafka-cluster-id $KAFKA_ID Use the following command to grant full access for the |ksqldb| |rbac-sa| to the |ksqldb| processing log topic. .. code:: bash # Grant full access for the ksql service principal to the ksqlDB processing log topic. confluent iam rbac role-binding create \ --principal User:ksql \ --role ResourceOwner \ --resource Topic:${KSQLDB_ID}ksql_processing_log \ --kafka-cluster-id $KAFKA_ID Use the following command to grant ``DeveloperWrite`` access for the |ksqldb| |rbac-sa| to the ``Transactional-Id`` resource. .. code:: bash # Grant DeveloperWrite access for the ksql service principal to the Transactional-Id resource. confluent iam rbac role-binding create \ --principal User:ksql \ --role DeveloperWrite \ --resource Transactional-Id:${KSQLDB_ID} \ --kafka-cluster-id $KAFKA_ID Use the following command to grant full access for the ksql user to the ksqlDB consumer groups. .. code:: bash # Grant full access for the ksql service principal to the ksqlDB consumer groups. confluent iam rbac role-binding create \ --principal User:ksql \ --role ResourceOwner \ --resource Group:_confluent-ksql-${KSQLDB_ID} \ --prefix \ --kafka-cluster-id $KAFKA_ID Assign role for idempotent producers ==================================== To enable idempotent producers and exactly-once semantics (EOS), the |ksqldb| |rbac-sa| requires ``Write`` access to the |ak| cluster. .. note:: Any principal used by idempotent producers must be authorized as ``Write`` on the cluster. Binding either the ``DeveloperWrite`` or ``ResourceOwner`` RBAC roles on the |ak| cluster grants ``Write`` permission, but ``DeveloperWrite`` is the less permissive of the two roles and is the first recommendation. Consume does not require additional |ak| permissions to be idempotent consumers. The following role binding ensures that ``Write`` has access to the cluster: .. code:: bash # Grant Write access for the ksql service principal to the cluster. confluent iam rbac role-binding create \ --principal User:ksql \ --role DeveloperWrite \ --resource Cluster:kafka-cluster \ --kafka-cluster-id $KAFKA_ID # Grant Write access for the ksql service principal to the Transactional-Id resource. confluent iam rbac role-binding create \ --principal User:ksql \ --role DeveloperWrite \ --resource Transactional-Id:${KSQLDB_ID} \ --prefix \ --kafka-cluster-id $KAFKA_ID Assign roles for terminating a |ksqldb| cluster =============================================== To terminate a |ksqldb| cluster by calling the REST endpoint at ``/ksql/terminate``, a user must have the ``DeveloperManage`` role granted by a ``UserAdmin``. For more information, see :ksqldb-docs:`Terminate a cluster|developer-guide/ksqldb-rest-api/terminate-endpoint/`. |ksqldb| cluster scope ---------------------- Use the following command to assign a ``DeveloperManage`` role on the ksqlDB cluster. .. code:: bash confluent iam rbac role-binding create \ --principal User: \ --role DeveloperManage \ --kafka-cluster-id $KAFKA_ID \ --ksql-cluster-id $KSQLDB_ID \ --resource KsqlCluster:ksql-cluster .. _ksql-rbac-assign-roles-to-contribute: Assign roles for contributing to a |ksqldb| application ======================================================= To access the |ksqldb| cluster for development, an interactive user must have the following roles. |ksqldb| cluster scope ---------------------- Use the following command to assign the ``DeveloperWrite`` role on the |ksqldb| cluster. .. code:: bash # Grant write access for a user to resources on the ksqlDB cluster. confluent iam rbac role-binding create \ --principal User:$USER_NAME \ --role DeveloperWrite \ --kafka-cluster-id $KAFKA_ID \ --ksql-cluster-id $KSQLDB_ID \ --resource KsqlCluster:ksql-cluster Kafka cluster scope ------------------- Use the following command to assign the ``DeveloperRead`` role on the internal consumer groups for transient queries. .. code:: bash # Grant read-only access for a user to the ksqlDB consumer groups. confluent iam rbac role-binding create \ --principal User:$USER_NAME \ --role DeveloperRead \ --resource Group:_confluent-ksql-${KSQLDB_ID} \ --prefix \ --kafka-cluster-id $KAFKA_ID Assign the following role if the interactive user needs access to the |ksqldb| processing log. .. code:: bash # Grant access for a user to the processing log. confluent iam rbac role-binding create \ --principal User:$USER_NAME \ --role DeveloperRead \ --resource Topic:${KSQLDB_ID}ksql_processing_log \ --kafka-cluster-id $KAFKA_CLUSTER_ID .. _config-security-ksql-grant-access: Grant a user access to resources ================================ In addition to the minimum necessary roles, an interactive user needs roles to access specific resources like topics, consumer groups, and subjects. .. important:: When you grant roles to a user, remember to grant the same roles to the |ksqldb| |rbac-sa|, which is named "ksql" by default. Prefixed resource names ----------------------- Use the ``prefix`` option in the |confluent-cli| to grant access to all resources with names that start with the specified prefix string. For example, to grant read-only access to all topics that start with ````, you could use the following command. .. code:: bash # Grant read-only access for a user to a topic. confluent iam rbac role-binding create \ --principal User:$USER_NAME \ --role DeveloperRead \ --resource Topic: \ --prefix \ --kafka-cluster-id $KAFKA_ID Roles for accessing topics, streams, and tables ----------------------------------------------- Use the following |confluent-cli| commands to give an interactive user the necessary roles for creating streams and table. SHOW or PRINT a topic - ``ResourceOwner`` role on the |ak| topic - ``DeveloperRead`` role on the |sr| subject, if the topic has an Avro, Protobuf, or JSON_SR schema This role enables an interactive user to display the specified topic by using the SHOW and PRINT statements. Also, users can CREATE streams and tables from these topics. The |ksqldb| |rbac-sa| doesn't need a role on the topic for these statements. .. note:: The subject's name is the topic's name appended with ``-value``. .. code:: bash # Grant read-only access for a user to read a topic. confluent iam rbac role-binding create \ --principal User:$USER_NAME \ --role ResourceOwner \ --resource Topic:$TOPIC_NAME \ --kafka-cluster-id $KAFKA_ID .. code:: bash # Grant read-only access for a user to read a subject. confluent iam rbac role-binding create \ --principal User:$USER_NAME \ --role DeveloperRead \ --resource Subject:${TOPIC_NAME}-value --kafka-cluster-id $KAFKA_ID \ --schema-registry-cluster-id $SR_ID SELECT from a stream or table - ``ResourceOwner`` role on the source topic - ``DeveloperRead`` role on the ``_confluent-ksql-${KSQLDB_ID}`` consumer group - ``ResourceOwner`` role on the ``_confluent-ksql-${KSQLDB_ID}transient`` transient topics, for tables - ``DeveloperRead`` role on the |sr| subject, if the topic has an Avro, Protobuf, or JSON_SR schema - ``ResourceOwner`` role on the ``_confluent-ksql-transient*`` subjects, for tables that use Avro (not required for streams) These roles enable a user to read from a stream or a table by using the SELECT statement. If a SELECT statement contains a JOIN that uses an unauthorized topic, the SELECT fails with an authorization error. .. code:: bash # Grant read-only access for a user to read a topic. confluent iam rbac role-binding create \ --principal User:$USER_NAME \ --role ResourceOwner \ --resource Topic:$TOPIC_NAME \ --kafka-cluster-id $KAFKA_ID .. code:: bash # For tables: grant access to the transient query topics. # This is a limitation of ksqlDB tables. Giving this permission to # the prefixed topics lets the user view tables from other queries. confluent iam rbac role-binding create \ --principal User:$USER_NAME \ --role ResourceOwner \ --resource Topic:_confluent-ksql-${KSQLDB_ID}transient \ --prefix \ --kafka-cluster-id $KAFKA_CLUSTER_ID # For tables that use Avro: grant access to the transient subjects. confluent iam rbac role-binding create \ --principal User:$USER_NAME \ --role ResourceOwner \ --resource Subject:_confluent-ksql-${KSQLDB_ID}transient \ --prefix \ --kafka-cluster-id $KAFKA_CLUSTER_ID \ --schema-registry-cluster-id $SR_ID .. code:: bash # Grant read-only access for a user to read from a consumer group. confluent iam rbac role-binding create \ --principal User:$USER_NAME \ --role DeveloperRead \ --resource Group:_confluent-ksql-${KSQLDB_ID} \ --prefix \ --kafka-cluster-id $KAFKA_ID .. code:: bash # Grant read-only access for a user to read a subject. confluent iam rbac role-binding create \ --principal User:$USER_NAME \ --role DeveloperRead \ --resource Subject:${TOPIC_NAME}-value --kafka-cluster-id $KAFKA_ID \ --schema-registry-cluster-id $SR_ID Write to a topic with INSERT - ``DeveloperWrite`` role on the |ak| topic - ``ResourceOwner`` or ``DeveloperWrite`` role on the |sr| subject, if the topic has an Avro, Protobuf, or JSON_SR schema These roles enable a user to write data by using INSERT statements. The INSERT INTO statement contains a SELECT clause that requires the user to have read permissions on the topic in the query. .. code:: bash # Grant write access for a user to a topic. confluent iam rbac role-binding create \ --principal User:$USER_NAME \ --role DeveloperWrite \ --resource Topic:$TOPIC_NAME \ --kafka-cluster-id $KAFKA_ID .. code:: bash # Grant full access for a user to create a subject and write to it. confluent iam rbac role-binding create \ --principal User:$USER_NAME \ --role ResourceOwner \ --resource Subject:${TOPIC_NAME}-value --kafka-cluster-id $KAFKA_ID \ --schema-registry-cluster-id $SR_ID CREATE STREAM - ``ResourceOwner`` role on the source topic - ``DeveloperRead`` role on the ``_confluent-ksql-${KSQLDB_ID}`` consumer groups - ``ResourceOwner`` or ``DeveloperWrite`` role on the |sr| subject, if the source topic has an Avro, Protobuf, or JSON_SR schema These roles enable an interactive user to register a stream or table on the specified topic by using the CREATE STREAM statement. If the topic has an Avro, Protobuf, or JSON_SR schema, the interactive user and the |ksqldb| |rbac-sa| must have full access for the subject in |sr|. .. code:: bash # Grant read-only access for a user to a topic. confluent iam rbac role-binding create \ --principal User:$USER_NAME \ --role ResourceOwner \ --resource Topic:$TOPIC_NAME \ --kafka-cluster-id $KAFKA_ID # Grant read-only access for the ksql service principal to a topic. confluent iam rbac role-binding create \ --principal User:ksql \ --role ResourceOwner \ --resource Topic:$TOPIC_NAME \ --kafka-cluster-id $KAFKA_ID .. code:: bash # Grant read-only access for a user to the ksqlDB consumer groups. confluent iam rbac role-binding create \ --principal User:$USER_NAME \ --role DeveloperRead \ --resource Group:_confluent-ksql-${KSQLDB_ID} \ --prefix \ --kafka-cluster-id $KAFKA_ID # Grant read-only access for the ksqlDB service principal to the ksqlDB consumer groups. confluent iam rbac role-binding create \ --principal User:ksql \ --role DeveloperRead \ --resource Group:_confluent-ksql-${KSQLDB_ID} \ --prefix \ --kafka-cluster-id $KAFKA_ID .. code:: bash # Grant full access for a user to create a subject and write to it. confluent iam rbac role-binding create \ --principal User:$USER_NAME \ --role ResourceOwner \ --resource Subject:${TOPIC_NAME}-value \ --kafka-cluster-id $KAFKA_ID \ --schema-registry-cluster-id $SR_ID # Grant full access for the ksqlDB service principal to create a subject and write to it. confluent iam rbac role-binding create \ --principal User:ksql \ --role ResourceOwner \ --resource Subject:${TOPIC_NAME}-value \ --kafka-cluster-id $KAFKA_ID \ --schema-registry-cluster-id $SR_ID CREATE TABLE - ``ResourceOwner`` role on the source topic - ``ResourceOwner`` role on the ``_confluent-ksql-${KSQLDB_ID}transient`` transient topics - ``ResourceOwner`` or ``DeveloperWrite`` role on the |sr| subject, if the source topic has an Avro, Protobuf, or JSON_SR schema - ``ResourceOwner`` role on ``_confluent-ksql-${KSQLDB_ID}*`` subjects (for tables that use Avro, Protobuf, or JSON_SR) These roles enable an interactive user to register a table on the specified topic by using the CREATE TABLE statement. If the topic has an Avro, Protobuf, or JSON_SR schema, the interactive user and the |ksqldb| |rbac-sa| must have full access for the subject in |sr|. .. note:: The ``ResourceOwner`` role on the transient topics is a limitation of KSQL tables. Giving this permission to the prefixed topics lets the user view tables from other queries. .. code:: bash # Grant read-only access for a user to a topic. confluent iam rbac role-binding create \ --principal User:$USER_NAME \ --role ResourceOwner \ --resource Topic:$TOPIC_NAME \ --kafka-cluster-id $KAFKA_ID # Grant read-only access for ksql service principal to a topic. confluent iam rbac role-binding create \ --principal User:ksql \ --role ResourceOwner \ --resource Topic:$TOPIC_NAME \ --kafka-cluster-id $KAFKA_ID .. code:: bash # Grant full access for a user to the transient query topics. # This is a limitation of ksqlDB tables. Giving this permission to # the prefixed topics lets the user view tables from other queries. confluent iam rbac role-binding create \ --principal User:$USER_NAME \ --role ResourceOwner \ --resource Topic:_confluent-ksql-${KSQLDB_ID}transient \ --prefix \ --kafka-cluster-id $KAFKA_ID # Grant full access for the ksql service principal to ksqlDB transient topics. confluent iam rbac role-binding create \ --principal User:ksql \ --role ResourceOwner \ --resource Topic:_confluent-ksql-${KSQLDB_ID}transient \ --prefix \ --kafka-cluster-id $KAFKA_ID .. code:: bash # Grant full access for a user to create a subject and write to it. confluent iam rbac role-binding create \ --principal User:$USER_NAME \ --role ResourceOwner \ --resource Subject:${TOPIC_NAME}-value \ --kafka-cluster-id $KAFKA_ID \ --schema-registry-cluster-id $SR_ID # Grant full access for the ksql service principal to create a subject and write to it. confluent iam rbac role-binding create \ --principal User:ksql \ --role ResourceOwner \ --resource Subject:${TOPIC_NAME}-value \ --kafka-cluster-id $KAFKA_ID \ --schema-registry-cluster-id $SR_ID # For tables that use Avro, Protobuf, or JSON_SR: # Grant full access for the ksql service principal to all internal ksql subjects. confluent iam rbac role-binding create \ --principal User:ksql \ --role ResourceOwner \ --resource Subject:_confluent-ksql-${KSQLDB_ID} \ --prefix \ --kafka-cluster-id $KAFKA_ID \ --schema-registry-cluster-id $SR_ID Create a stream or table with a persistent query - ``ResourceOwner`` role on the source topic - ``ResourceOwner`` role on the |ksqldb| sink topic - ``ResourceOwner`` or ``DeveloperWrite`` role on the |sr| sink subject, if the source topic has an Avro, Protobuf, or JSON_SR schema - ``DeveloperRead`` role on ``_confluent-ksql-${KSQLDB_ID}*`` subjects (for tables that use Avro, Protobuf, or JSON_SR) These roles enable a user to create streams and tables with persistent queries. Because |ksqldb| creates a new *sink topic*, the user must have sufficient permissions to create, read, and write to the sink topic. The ``ResourceOwner`` role is necessary on the sink topic, because the interactive user and the |ksqldb| |rbac-sa| need permissions to create the sink topic if it doesn't exist already. .. note:: The sink topic has the same name as the stream or table and is all uppercase. If the topic has an Avro schema, the interactive user and the |ksqldb| |rbac-sa| must have ``ResourceOwner`` or ``DeveloperWrite`` permission on the sink topic's subject in |sr|. For tables that are created with a persistent query and use Avro, Protobuf, or JSON_SR the |ksqldb| |rbac-sa| must have ``DeveloperRead`` permission on all internal subjects. .. note:: The subject's name is the sink topic's name appended with ``-value``. .. code:: bash # Grant read-only access for a user to a topic. confluent iam rbac role-binding create \ --principal User:$USER_NAME \ --role ResourceOwner \ --resource Topic:$SOURCE_TOPIC_NAME \ --kafka-cluster-id $KAFKA_ID # Grant read-only access for the ksql service principal to a topic. confluent iam rbac role-binding create \ --principal User:ksql \ --role ResourceOwner \ --resource Topic:$SOURCE_TOPIC_NAME \ --kafka-cluster-id $KAFKA_ID .. code:: bash # Grant read-only access for a user to a topic. confluent iam rbac role-binding create \ --principal User:$USER_NAME \ --role ResourceOwner \ --resource Topic:$SINK_TOPIC_NAME \ --kafka-cluster-id $KAFKA_ID # Grant read-only access for the ksql service principal to a topic. confluent iam rbac role-binding create \ --principal User:ksql \ --role ResourceOwner \ --resource Topic:$SINK_TOPIC_NAME \ --kafka-cluster-id $KAFKA_ID .. code:: bash # Grant full access for a user to create a subject and write to it. confluent iam rbac role-binding create \ --principal User:$USER_NAME \ --role ResourceOwner \ --resource Subject:${SINK_TOPIC_NAME}-value \ --kafka-cluster-id $KAFKA_ID \ --schema-registry-cluster-id $SR_ID # Grant full access for the ksql service principal to create a subject and write to it. confluent iam rbac role-binding create \ --principal User:ksql \ --role ResourceOwner \ --resource Subject:${SINK_TOPIC_NAME}-value \ --kafka-cluster-id $KAFKA_ID \ --schema-registry-cluster-id $SR_ID # For tables that use Avro, Protobuf, or JSON_SR created with a persistent query: # Grant read access for the ksql service principal to all internal ksql subjects. confluent iam rbac role-binding create \ --principal User:ksql \ --role DeveloperRead \ --resource Subject:_confluent-ksql-${KSQLDB_ID} \ --prefix \ --kafka-cluster-id $KAFKA_ID \ --schema-registry-cluster-id $SR_ID Full control over a topic and schema - ``ResourceOwner`` role on the |ak| topic - ``ResourceOwner`` role on the |sr| subject, if the topic has an Avro, Protobuf, or JSON_SR schema Use the following commands to grant a user full control over a topic and its schema, including permissions to delete the topic and schema. .. code:: bash # Grant full access for a user to manage a topic. confluent iam rbac role-binding create \ --principal User:$USER_NAME \ --role ResourceOwner \ --resource Topic:$TOPIC_NAME \ --kafka-cluster-id $KAFKA_ID .. code:: bash # Grant full access for a user to manage a subject. confluent iam rbac role-binding create \ --principal User:$USER_NAME \ --role ResourceOwner \ --resource Subject:${TOPIC_NAME}-value --kafka-cluster-id $KAFKA_ID \ --schema-registry-cluster-id $SR_ID Delete a topic - ``DeveloperManage`` role on the |ak| topic - ``DeveloperManage`` role on the |sr| subject, if the topic has an Avro, Protobuf, or JSON_SR schema These roles enable a user to delete a topic by using the DROP STREAM/TABLE [DELETE TOPIC] statements. Use the following commands to grant a user delete access to a topic and corresponding schema. .. code:: bash # Grant delete access for a user to a topic. confluent iam rbac role-binding create \ --principal User:$USER_NAME \ --role DeveloperManage \ --resource Topic:$TOPIC_NAME \ --kafka-cluster-id $KAFKA_ID .. code:: bash # Grant delete access for a user to a subject. confluent iam rbac role-binding create \ --principal User:$USER_NAME \ --role DeveloperManage \ --resource Subject:${TOPIC_NAME}-value --kafka-cluster-id $KAFKA_ID \ --schema-registry-cluster-id $SR_ID