ACL Rights Management

ACL Rights Management

The rights to manage or view ACLs can be configured flexibly: from basic rights that cover all ACLs to resource-specific rights with specifications on the naming scheme.
The latter allows teams to independently manage resources within their working context.
In combination with the topic rights, which also allow naming specifications (e.g. via prefix or postfix), a team "Marketing" can thus be enabled to manage all marketing topics, associated topic-, transactionalId- and consumer group ACLs on its own.

Scope of rights

A variety of rights are available for fine-grained control of actions for ACLs:
  1. Read
  2. Write
  3. Delete
  4. Full access (all above)
Rights for these actions can be assigned per connection and per resource type (e.g. Acl for topics or consumer groups). In addition, a naming convention can be enforced for the resource name of the ACL: in the case of a topic ACL, the name of one or, if the asterisk is used, several topics can be specified for which the ACL can be created.

The following resource types can be optionally specified:
  1. cluster
  2. group
  3. topic
  4. transactional_id

Allow full access

Using the Rights Builder to give access to manage and view all ACL resources, select ‘AclAccessAll’ in the action dropdown and click on all for the resource name.
To configure the right in the JSON view, use the following code:
{
    "action": "AclAccessAll",
    "effect": "Allow",
    "resource": "*:*"
}

The first asterisk in the resource string represents the id of your connection, the second asterisk the resource name. To limit the right to a connection with id 2:

{
    "action": "AclAccessAll",
    "effect": "Allow",
    "resource": "2:*"
}

Allow all access to specific ACL resources

Using the Rights Builder to enable full access to only resource type related ACLs , select ‘AclAccessAll’ in the action dropdown and enter the resource type:
*:topic

The JSON representation looks like this:
{
    "action": "AclAccessAll",
    "effect": "Allow",
    "resource": "*:*:topic"
}

Allow all access to ACL resources with name spaces / resource name patterns

Using the Rights Builder to enable full access to only topic related ACLs for topics that start with myteam-, select 'AclAccessAll' in the action dropdown and enter the resource name:
myteam-*:topic

The JSON representation looks like this:
{
    "action": "AclAccessAll",
    "effect": "Allow",
    "resource": "*:myteam-:topic"
}

Available resource types

You can define ACL rights for specific resource types. The following resource types are supported:
  2. cluster
  3. group
  4. topic
  5. transactional_id

Cluster

To enable access to ACLs for the cluster:
kafka-cluster:cluster

Consumer groups

To enable access to ACLs for consumer groups that start with a certain name:
consumergroup-prefix-*:group

Topics

To enable access to ACLs for topics that start with a certain name:
topic-prefix-*:topic

Transactional Ids

To enable access to ACLs for transactional ids that start with a certain name:
transactional_id-prefix-*:transactional_id

Recommended use for self-managing teams

The following is a recommendation to allow self-management within a project or domain context for a specific team:
  1. Create a new role.
  2. Add the Topic right "TopicAccessAll" with a naming scheme, e.g. "marketing.*" for all marketing topics to allow full management of all marketing topics.
Create multiple ACL rights as follows:
  1. AclAccessAll with the resource name "marketing.*:topic".
  2. AclAccessAll with the resource name "marketingteam*:group".
  3. If applicable, AclAccessAll with the resource name "marketingteam*:transactional_id".
Thus, the marketing team has the following rights:
  1. It can manage independent topics starting with the name "marketing.".
  2. It can independently manage Acls for topics mentioned in the point above.
  3. It can independently manage Acls for Consumer groups and Transactional Ids that start with their team name "marketingteam".

    • Related Articles

    • Rights evaluation

      You can assign multiple roles with multiple rights to a user. The following rules apply to evaluate the rights in effect: First Rule: Specific right before less specific right. Second Rule: Allow before deny. Rule 1 example: Right1: Deny      ...

    • Manage rights and roles

      What are roles? Roles are a collection of rights that can be assigned either to groups or directly to users. The rights define the scope of functionality and data to which a user has access. Create roles and rights Go to the Roles screen in the ...

    • Kafka Connect Rights Management

      To view or manage Kafka Connect connectors or task, the user must have both the KafkaConnectView right and the KafkaConnectManage right. KafkaConnectView and KafkaConnectManage can be assigned for individual connections/environments. Example rights: ...

    • Quota Management

      A quota can be applied to limit network and resource utilization for Kafka to only specific users and/or clients. To use user level quotas, authentication via Kerberos or TLS certificates must be enabled in your Apache Kafka setup. Note that ...

    • Quick Processor Rights Management

      To modify or create a Quick Processor, the user must have both the QuickProcessorModify right and the TopicAccessRead right. QuickProcessorModify can be assigned for individual connections/environments. In combination with the TopicAccessRead right, ...