# Use Predefined RBAC Roles in Confluent Platform Confluent Platform provides predefined roles to help implement granular permissions for specific resources and to simplify access control across the Confluent Platform. A predefined role is a Confluent-defined job function that is assigned a set of permissions required to perform specific actions or operations on Confluent resources. Each role is bound to a principal and Confluent resources. Users can have multiple roles assigned to them. You cannot use a predefined role to override denial-of-access (DENY) that is configured in an ACL. When a role is assigned at the **cluster-level** (Kafka cluster, Schema Registry cluster, ksqlDB cluster, or Connect cluster) it means that users who are assigned this role have access to all resources in a cluster. For example, the `ClusterAdmin` of a Kafka cluster has access to Confluent Control Center alerts. There are corresponding resource types for each cluster type. For example, you can assign the `ResourceOwner` role to the resource types `KsqlCluster:ksql-cluster` or `Cluster:kafka-cluster` to provide a user all the `ResourceOwner` privileges for a ksqlDB or Kafka cluster. When a role is assigned at the **resource-level** it means that users assigned this role only have access to specific resources as defined in the role binding. The resource types for which you can assign RBAC roles and role bindings are: - Kafka cluster - Topic - Consumer group - TransactionalID - Schema Registry cluster - Schema Registry subject - ksqlDB cluster - Connect cluster - Connector - Kek (CSFLE key resource in Schema Registry) Confluent Platform provides the following predefined roles: | Role Name | Level of Role Scope | View Role Bindings of Others | Manage Role Bindings | Monitor | Resource Read | Resource Write | Resource Manage | |-------------------|-----------------------|--------------------------------|------------------------|-----------|-----------------|------------------|------------------------| | `super.user` | Cluster | Yes | Yes | Yes | Yes | Yes | Yes | | `SystemAdmin` | Cluster | Yes | Yes | Yes | Yes | Yes | Yes | | `ClusterAdmin` | Cluster | No | No | Yes | No | No | Yes | | `UserAdmin` | Cluster | Yes | Yes | No | No | No | No | | `SecurityAdmin` | Cluster | Yes | No | No | No | No | No | | `AuditAdmin` | Cluster | No | No | No | No | No | Yes [(1)](#role-notes) | | `Operator` | Cluster | No | No | Yes | No | No | Yes [(2)](#role-notes) | | `ResourceOwner` | Resource | Yes | Yes | No | Yes | Yes | Yes | | `DeveloperRead` | Resource | No | No | No | Yes | No | No | | `DeveloperWrite` | Resource | No | No | No | No | Yes | No | | `DeveloperManage` | Resource | No | No | No | No | No | Yes | Notes: : 1. The AuditAdmin role provides sufficient access for creating and managing the audit log configuration. 2. For Operator Resource Manage, Operators can only pause, resume, and scale Connectors. super.user : The purpose of `super.user` is to have a bootstrap user who can initially grant another user the `SystemAdmin` role. Technically speaking, `super.user` is not a predefined role. It is a `server.properties` attribute that defines a user who has full access to all resources within a Metadata Service (MDS) cluster. A `super.user` has no access to resources in other clusters (unless also configured as a `super.user` on other clusters).
Permissions granted by `super.user` apply only to the broker where the `super.user` attribute is specified. No authorization is enforced on users defined as `super.user`. It is strongly recommended that this role is assigned only to a limited number of users (for example, 1-2 users who are responsible for bootstrapping).
The `super.user` permission does not apply to other brokers, clusters, or Confluent Platform components such as Schema Registry, ksqlDB, and so forth. To be a true super user on these components the user must be listed in the `super.users` configuration and be a `SystemAdmin`. Using `SystemAdmin` in combination with `super.users` for component-specific tasks can lead to excessive privileges and is generally only required for initial setup or broad cluster-level operations. SystemAdmin : Provides full access to all scoped [resources](overview.md#rbac-resource) in the cluster (ksqlDB cluster, Kafka cluster, or Schema Registry cluster).
For managing specific components or resources, `SystemAdmin` is unnecessary, only the relevant RBAC roles are necessary `ClusterAdmin`, `ResourceOwner`, `KsqlAdmin` for ksqlDB, `DeveloperManage` for Schema Registry, and so forth. These more granular roles provide targeted permissions, adhering to the principle of least privilege, which enhances security and simplifies auditing.
It is strongly recommended that you restrict `SystemAdmin` to a limited number of users (one or two per cluster) who need full permission for initial setup or to address urgent issues when absolutely necessary in production instances. You may wish to assign this role more liberally in small test and development use cases, or when working in ksqlDB clusters that are primarily single tenant. Otherwise, it is recommended that you do not assign the `SystemAdmin` role. ClusterAdmin : Provisions, configures, and maintains clusters. ClusterAdmin is responsible for:
* Provisioning and managing Kafka clusters, brokers, networking, ksqlDB clusters, Connect clusters * Scaling clusters by adding or removing nodes * Performing system upgrades
**Scope and Permissions**
The `ClusterAdmin` role binds at the cluster level (`bindWithResource: false`). It grants permissions cluster-wide across all resource types with specific data-access limitations:
* **Topic access**: Restricted. This role cannot read or write Kafka topic data because it does not have `Read` or `Write` operations on `Topic`. * **Schema access**: Full access. This role has read and write access to Schema Registry `Subject` resources (schemas).
Assign this role to operators responsible for system health and performance.
After creating topics, the `ClusterAdmin` can transfer ownership to a user with the `ResourceOwner` role to manage data-level permissions.
The following table lists the resource types and allowed operations for the role:
| Resource type | Allowed operations | |------------------------------|---------------------------------------------------------------------------------------------------| | `Cluster` | Create, Alter, AlterConfigs, Describe, DescribeConfigs | | `Topic` | Create, Delete, Alter, AlterConfigs, Describe, DescribeConfigs | | `Subject` | Read, Write, Delete, ReadCompatibility, WriteCompatibility | | `Kek` | Register, Read, Update, Deregister | | `Connector` | Create, ReadConfig, ReadStatus, ReadActiveTopics, Pause, Resume, Scale, Delete, ResetActiveTopics | | `Secret` | Create, Read, Delete | | `KsqlCluster` | Contribute, Terminate | | `ControlCenterBrokerMetrics` | Read | | `ControlCenterAlerts` | Read, Write | | `ClusterRegistry` | Alter, Describe | | `FlinkApplication` | Start, Suspend, Edit, Remove, View, AccessWebUI | | `FlinkStatement` | Edit, Remove, View, AccessWebUI | | `FlinkComputePool` | Edit, Remove, View, AccessWebUI | | `FlinkEnvironment` | Edit, Remove, View | | `FlinkKubernetesCluster` | View, Attach, Use | | `FlinkCatalog` | Edit, Remove, View | | `FlinkSecret` | Edit, Remove, View | | `FlinkDetachedSavepoint` | Edit, Remove, View | | `FlinkArtifact` | View, Edit, Remove, Use | UserAdmin : Manages role bindings for users and groups in all clusters managed by MDS.
Manages users and groups in a cluster, including the mapping of users and groups to roles. Has no access to any other resources. Typically, users with the `UserAdmin` role are tasked with setting up access to [resources](overview.md#rbac-resource). Users granted this role should be extremely trustworthy because they can grant roles to themselves and others. You can monitor the actions of the `UserAdmin` using audit logs. SecurityAdmin : Enables management of platform-wide security initiatives.
Sets up security-related features (for example, encryption, tracking of audit logs, and watching for abnormal behavior). Provides a dedicated set of users for the initial setup and ongoing management of security functions. AuditAdmin : Users or groups assigned this role on the MDS cluster and every registered Kafka cluster can manage the audit log configuration using the [Confluent Metadata API](mds-api.md#mds-api). Operator : Provides operational management of clusters and scale applications as needed.
Monitors the health of applications and clusters, including monitoring uptime. This role cannot create applications, nor does it allow you to view or edit the content of the topics. However, you can view what topics and partitions exist. ResourceOwner : Transfers the ownership of critical resources and to scale the ability to manage authorizations for those resources.
Owns the [resource](overview.md#rbac-resource) and has full access to it, including read, write, and list. ResourceOwner can grant permission to others who need access to resources. Owner cannot change some of the configurations, for example the number of partitions. Must own the resource to grant others access to it. Enables scaling of authorization for critical resources. DeveloperRead : Allows developers to read from resources needed to build and run an application.
**Scope and Permissions**
The `DeveloperRead` role binds to a specific resource (`bindWithResource: true`). It grants read and describe access to that resource. It does not grant write, alter, or resource-management operations.
The following table lists the resource types and allowed operations for the role:
| Resource type | Allowed operations | |-------------------|------------------------------------------| | `Topic` | Read, Describe | | `Group` | Read, Describe | | `TransactionalId` | Describe | | `Subject` | Read, ReadCompatibility | | `Kek` | Read | | `Connector` | ReadConfig, ReadStatus, ReadActiveTopics | DeveloperWrite : Allows developers to write to resources needed to build and run an application.
**Scope and Permissions**
The `DeveloperWrite` role binds to a specific resource (`bindWithResource: true`). It grants write access along with the describe operations needed to produce data. It does not grant read or resource-management operations on topics, and it does not include access to consumer groups.
The following table lists the resource types and allowed operations for the role:
| Resource type | Allowed operations | |-------------------|------------------------------------------------------------| | `Topic` | Write, Describe | | `TransactionalId` | Write, Describe | | `Cluster` | IdempotentWrite | | `Subject` | Write, ReadCompatibility | | `Kek` | Register, Read, Update | | `Connector` | ReadStatus, ReadActiveTopics, Configure, ResetActiveTopics | | `KsqlCluster` | Contribute | DeveloperManage : Allows developers to create and delete resources and manage their lifecycle, for example creating or deleting a topic.
**Scope and Permissions**
The `DeveloperManage` role binds to a specific resource (`bindWithResource: true`). It grants lifecycle operations, such as create or delete, and the ability to view configuration (`DescribeConfigs`), but it does not grant `Alter` or `AlterConfigs`. A principal with only `DeveloperManage` on a topic can create or delete that topic but cannot change its configuration. For example, `retention.ms` or partition count. To alter topic configuration, a principal needs the `ResourceOwner` or `ClusterAdmin` role. For more information, see the table below.
| Resource type | Allowed operations | |-------------------|-------------------------------------------------------------------------------| | `Topic` | Create, Delete, Describe, DescribeConfigs | | `Group` | Describe, DescribeConfigs, Delete | | `TransactionalId` | Describe | | `Cluster` | Create, DescribeConfigs | | `Subject` | ReadCompatibility, WriteCompatibility | | `Connector` | Create, ReadStatus, ReadActiveTopics, Pause, Resume, Scale, ResetActiveTopics | | `KsqlCluster` | Terminate | ## RBAC role use cases These use cases are based on a new project where security is managed using RBAC predefined roles as follows: | Predefined Role | Plan | |------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | `super.user` | Sam is granted full access to all project resources and operations. He will create the initial set of roles for the project. | | `ResourceOwner` | Ryan will own all topics with the prefix `finance_`. He can grant others permission to access and use this resource. In this use case, he is the `ResourceOwner` for the finance topics. | | `UserAdmin` | Uri will manage the users and groups for the project. | | `Operator` | Olivia will be responsible for the operational and health management of the platform and applications. | | `ClusterAdmin` | Cindy is a member of the Kafka cluster central team. | | `DeveloperRead`, `DeveloperWrite`, `DeveloperManage` | David will be responsible for developing and managing the application. | The use cases below guide you through the application of predefined roles to illustrate one possible way you can leverage and use RBAC predefined roles. ### Project started by super.user During the initial configuration, Sam is granted `super.user` access through the configuration file. Now Sam has access to all the resources within the Kafka cluster that is hosting MDS, and also can create role bindings to any resource managed by MDS. **Roles**: `super.user` ### Invite (using corporate tools like JIRA) users to build Confluent Platform Sam sets up role bindings for users and groups: * Uri granted `UserAdmin` role to manage users/groups * If needed, Sam can grant the `SystemAdmin` role for the cluster to others (only if absolutely necessary). **Roles**: `UserAdmin`, `SystemAdmin` ### UserAdmin defines and assigns roles Uri takes the following actions: * If needed, Uri creates new groups in corporate LDAP (for example, Kafka developer group) making it easier to manage role bindings for multiple users at the same time. * Grants Ryan `ResourceOwner` role on topics that use the prefix `s`. * Grants Olivia `Operator` role on a Connect cluster so she can manage operations. * Grants Cindy the `ClusterAdmin` role. Now Cindy can manage clusters. **Roles**: `UserAdmin`, `ResourceOwner`, `ClusterAdmin`, `Operator` ### ClusterAdmin creates topics and other resources Cindy joins the project to manage a Kafka cluster. She: * Manages brokers and updates configurations as needed. * Receives a request to create topics for the finance development team: * She creates topics with the `finance_` prefix. * She can’t read or write to these topics. **Roles**: `ClusterAdmin` ### Data governance is implemented * Ryan has `ResourceOwner` rights to all the topics prefixed with `finance_,` so he can view all these topics. * Ryan grants appropriate access rights for all topics with the prefix `finance_`. * Ryan is notified through the existing corporate workflow that there is a request for access to topics and other critical resources to which he can grant or deny access. **Roles**: `ResourceOwner` ### Developer creates applications David needs to create a new application that produces to a topic (`finance_report`). * If David has not already been added as a developer (through user/group mapping by Uri), then he must request access from Ryan. * Ryan (`ResourceOwner`) grants David the `DeveloperWrite` role on the topic `finance_report`. * Ryan (`ResourceOwner`) can grant David the `DeveloperRead` or `DeveloperManage` roles too, depending on what kind of operations David’s application needs to perform. **Roles**: `DeveloperWrite`, `DeveloperRead`, `DeveloperManage` ### Monitor health of the cluster and take proper actions Olivia is responsible for managing the health of the resources in the cluster and takes actions when necessary. For example, if a connector has performance issues then she can increase the number of instances or scale them up. **Roles**: `Operator` ## RBAC role use cases for Confluent Platform for Apache Flink Confluent Manager for Apache Flink supports all available RBAC authentication options to authenticate with the Confluent Platform metadata service. The following examples cover some authentication methods for the metadata service. ### OAuth example The following YAML file shows how you might configure mTLS authentication for CMF with Oauth authentication with MDS. ```yaml # authorization-values.yaml cmf: authorization: mdsRestConfig: endpoint: #Mandatory: replace with the endpoint for the Metadata Service authentication: type: oauth config: confluent.metadata.http.auth.credentials.provider: OAUTHBEARER confluent.metadata.oauthbearer.token.endpoint.url: #URL of your configured IDP used to store the users confluent.metadata.oauthbearer.login.client.id: #Client id for the user talking to MDS, needs to be a user that can request permissions for all users confluent.metadata.oauthbearer.login.client.secret: #Client secret for the user talking to MDS # Required when MDS uses HTTPS: truststore to trust the MDS server certificate. confluent.metadata.ssl.truststore.location: #truststore path to trust the MDS server certificate confluent.metadata.ssl.truststore.password: #optional password if the truststore is password protected ``` When you make the `helm install` call, use the `-f` flag to pass the YAML file with the security information like the following: ```none helm upgrade --install cmf confluent/confluent-manager-for-apache-flink \ -f mtls-values.yaml \ -f authorization-values.yaml ``` #### NOTE When the MDS endpoint uses HTTPS, you must include `confluent.metadata.ssl.truststore.location` in the authentication configuration so that CMF can trust the MDS server certificate. You only need to include `confluent.metadata.ssl.truststore.password` if the truststore is password-protected. These settings are specific to the CMF-to-MDS connection and are separate from any server SSL configuration on CMF itself. ### mTLS example The following example shows how you configure mTLS authentication for CMF with mTLS authentication with MDS. ```yaml # authorization-values.yaml cmf: authorization: mdsRestConfig: endpoint: #Mandatory: replace with the endpoint for the Metadata Service authentication: type: mtls config: confluent.metadata.ssl.truststore.location: #truststore path containing certificates needed to talk to metadata service confluent.metadata.ssl.truststore.password: #optional password if truststore is encrypted confluent.metadata.ssl.keystore.location: #keystore path containing keys/certificates needed to talk to metadata service confluent.metadata.ssl.keystore.password: #optional password if keystore is encrypted confluent.metadata.ssl.key.password: ``` When you make the `helm install` call, use the `-f` flag to pass the YAML file with the security information like the following: ```none helm upgrade --install cmf confluent/confluent-manager-for-apache-flink \ -f mtls-values.yaml \ -f authorization-values.yaml ```