Grant producers and consumers access

Declare who may produce to a topic and who may consume from it in the topic’s own access block, and monedula-gitops creates the matching Kafka ACLs. For rules that no single topic owns, use a KafkaAccessPolicy.

Before you start

• A connecting principal that may manage ACLs, which takes Describe and Alter on the Cluster resource, or a super-user. A principal that is not a super-user can lock itself out once the topic’s ACLs exist.
• On Confluent Cloud, write principals with the service account’s numeric ID, such as User:9207877 (Supported platforms).

Steps

1. Add the access block

Save this manifest as manifests/topic.yaml, or add its access block to an existing KafkaTopic:

apiVersion: gitops.monedula.dev/v1alpha1
kind: KafkaTopic
metadata:
  name: acl-orders
spec:
  clusterRef:
    name: shared
  topicName: acl.orders
  partitions: 1
  access:
    producers:
      - principal: "User:svc-producer"
        operations:
          - Write
    consumers:
      - principal: "User:svc-consumer"
        group: acl-orders-cg
        topicOperations:
          - Read
        groupOperations:
          - Read

A producer needs a principal, and a consumer a principal and the group it reads with. Each entry compiles to Allow ACLs on the topic, plus the group for a consumer; Topic-centric access lists the default operations and the optional host. This manifest lists its operations explicitly, so it grants exactly three ACLs: Write on the topic for the producer, and Read on the topic and on the group for the consumer.

On a Confluent Platform cluster that authorizes with RBAC, the same block can compile to MDS role bindings instead of, or as well as, ACLs, as Manage Confluent RBAC role bindings shows.

2. Apply the manifest

monedula-gitops apply -f ./manifests --cluster-config-file ./cluster.yaml

kubectl apply -f manifests/

An Allow here that a KafkaAccessPolicy denies for the same principal, host, resource and operation is a conflict: the CLI exits 2, and the operator marks both resources with the ACLConflict condition.

3. Narrow or remove access

When you narrow an entry, for example drop an operation or change its host, the ACLs it no longer needs become PruneDisabled candidates and stay in Kafka until you opt in to pruning. With the CLI, add --prune:

monedula-gitops apply -f ./manifests --cluster-config-file ./cluster.yaml --prune

With the operator, set spec.prune: true on the KafkaTopic; Safety gates explains when the operator deletes a candidate.

Deleting an entry entirely, when no other manifest declares that principal on that resource, takes the pair out of the managed scope: its ACLs stay in Kafka, unreported, even with pruning on. Changing a consumer’s group leaves the old group’s ACLs behind the same way. To revoke that access, delete the leftover ACLs outside monedula-gitops, for example with Kafka’s kafka-acls tool.

Check it worked

monedula-gitops verify -f ./manifests --cluster-config-file ./cluster.yaml

kubectl get kafkatopic acl-orders -o jsonpath='{.status.conditions}'

verify exits 0 when the live topic and its ACLs match the manifest. With the operator, the Ready and TopicAccessSynced conditions have the status True. The broker now has three ACLs: Write on topic acl.orders for User:svc-producer, and Read on topic acl.orders and on group acl-orders-cg for User:svc-consumer.

Related

• The KafkaTopic reference lists every access field.
• Provision SCRAM users creates the credentials for the principals you grant access.
• Runnable version: scenarios/05-topic-with-access