.. _rbac-predefined-roles: Role-Based Access Control Predefined Roles ========================================== |cp| provides predefined roles to help implement granular permissions for specific resources and to simplify access control across the |cp|. 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** (|ak| cluster, |sr| cluster, |ksqldb| cluster, or |kconnect| cluster) it means that users who are assigned this role have access to all resources in a cluster. For example, the ``ClusterAdmin`` of a |ak| cluster has access to |c3| 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 |ak| 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: - |ak| cluster - Topic - Consumer group - TransactionalID - |sr| cluster - |sr| subject - |ksqldb| cluster - |kconnect| cluster - Connector |cp| provides the following predefined roles: ==================================== ============== ============================ ==================== ======= ============= ============== ============================ Role Name Role Scope View Role Bindings of Others Manage Role Bindings Monitor Resource Read Resource Write Resource Manage ==================================== ============== ============================ ==================== ======= ============= ============== ============================ super.user Cluster-level Yes Yes Yes Yes Yes Yes SystemAdmin Cluster-level Yes Yes Yes Yes Yes Yes ClusterAdmin Cluster-level No No Yes Yes Yes Yes UserAdmin Cluster-level Yes Yes No No No No SecurityAdmin Cluster-level Yes No No No No No AuditAdmin Cluster-level No No No No No Yes :ref:`(1) ` Operator Cluster-level No No Yes No No Yes :ref:`(2) ` ResourceOwner Resource-level Yes Yes No Yes Yes Yes DeveloperRead Resource-level No No No Yes No No DeveloperWrite Resource-level No No No No Yes No DeveloperManage Resource-level No No No No No Yes ==================================== ============== ============================ ==================== ======= ============= ============== ============================ .. _role-notes: Notes: #. The AuditAdmin role provides sufficient access for creating and managing the audit log configuration. #. 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 |mds-long| cluster. A ``super.user`` has no access to resources in other clusters (unless also configured as a ``super.user`` on other clusters). The primary use of super.user is to bootstrap |cp| and assign a SystemAdmin. On MDS clusters, ``super.user`` can create role bindings for all other clusters. Permissions granted by ``super.user`` apply only to the broker where the ``super.user`` attribute is specified, and not to other brokers, clusters, or |cp| components. 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). SystemAdmin Provides full access to all scoped :ref:`resources ` in the cluster (|ksqldb| cluster, |ak| cluster, or |sr| cluster). It is strongly recommended that this role is assigned only 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 this role. ClusterAdmin Sets up clusters (|ksqldb| cluster, |ak| cluster, or |sr| cluster). Responsible for setting up and managing |ak| clusters, brokers, networking, |ksqldb| clusters, |kconnect| clusters, and adding or removing nodes and performing upgrades. The ``ClusterAdmin`` typically creates topics and sets the properties of those topics, for example performance and capacity, but cannot read or write to topics, and has no access to data. For monitoring applications, it is recommended that this role is delegated to the operator who monitors your applications. Typically, the ``ClusterAdmin`` user does not possess knowledge about the content of the cluster data and he/she delegates the ownership responsibility of those resources to users assigned the ``ResourceOwner`` role. For example, after creating topics the ``ClusterAdmin`` can set ownership to a specific user familiar with the topic data. 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 :ref:`resources `. 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 |ak| cluster can manage the audit log configuration using the :ref:`Confluent Metadata 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 :ref:`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, DeveloperWrite, DeveloperManage Allows developers to drive the implementation of applications they are working on and manage the content. .. _rbac-roles-use-cases: 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 |ak| 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. +--------------------------------+-----------------------------------------------------------+--------------------------------+ | Use Case | Description | Roles | +================================+===========================================================+================================+ | Project started by | During the initial configuration, Sam is granted | super.user | | super.user | super.user access through the configuration file. | | | | Now Sam has access to all the resources within the |ak| | | | | cluster that is hosting MDS, and also can create role | | | | bindings to any resource managed by MDS. | | +--------------------------------+-----------------------------------------------------------+--------------------------------+ | Invite (using corporate tools | Sam sets up role bindings for users and groups: | UserAdmin, SystemAdmin | | like JIRA) users to build |cp| | | | | platform | * 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). | | +--------------------------------+-----------------------------------------------------------+--------------------------------+ | UserAdmin defines and assigns | Uri takes the following actions: | UserAdmin, ResourceOwner, | | roles | | ClusterAdmin, Operator | | | * If needed, Uri creates new groups in corporate LDAP | | | | (for example, |ak| 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 ``finance_``. | | | | * Grants Olivia Operator role on a |kconnect| cluster | | | | so she can manage operations. | | | | * Grants Cindy the ClusterAdmin role. Now Cindy can | | | | manage clusters. | | +--------------------------------+-----------------------------------------------------------+--------------------------------+ | ClusterAdmin creates topics | Cindy joins the project to manage a |ak| cluster. She: | ClusterAdmin | | and other resources | | | | | * 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 cannot read or write to these topics. | | +--------------------------------+-----------------------------------------------------------+--------------------------------+ | Data governance is implemented | * Ryan has ResourceOwner rights to all the topics | ResourceOwner | | | 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. | | +--------------------------------+-----------------------------------------------------------+--------------------------------+ | Developer creates applications | David needs to create a new application that produces | DeveloperWrite, DeveloperRead, | | | to a topic (``finance_report``). | DeveloperManage | | | | | | | * 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. | | +--------------------------------+-----------------------------------------------------------+--------------------------------+ | Monitor health of the cluster | Olivia is responsible for managing the health of the | Operator | | and take proper actions | 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. | | +--------------------------------+-----------------------------------------------------------+--------------------------------+