---
title: "Grant producers and consumers access"
description: "Use the access block of a KafkaTopic to generate producer and consumer ACLs for a topic and its consumer groups, in one manifest."
url: https://monedula.dev/flock/docs/gitops/how-to/grant-topic-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](/flock/docs/gitops/how-to/write-advanced-acl-rules/).

## 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](/flock/docs/gitops/how-to/connect-to-a-secured-cluster/) once the topic's ACLs exist.
- On Confluent Cloud, write principals with the service account's numeric ID, such as `User:9207877` ([Supported platforms](/flock/docs/gitops/concepts/supported-platforms/)).

## Steps

### 1. Add the access block

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

```yaml
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](/flock/docs/gitops/concepts/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](/flock/docs/gitops/how-to/manage-confluent-rbac/) shows.

### 2. Apply the manifest

<Tabs group="grant-topic-access-mode" labels={['CLI', 'Operator']} label="Where you run it">

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

```bash
kubectl apply -f manifests/
```

</Tabs>

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`:

<Callout type="warning">
Pruning deletes every live ACL in a declared principal and resource pair that your manifests do not list, including ACLs someone granted by hand before the manifest existed.
</Callout>

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

With the operator, set `spec.prune: true` on the `KafkaTopic`; [Safety gates](/flock/docs/gitops/concepts/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

<Tabs group="grant-topic-access-check" labels={['CLI', 'Operator']} label="Where you run it">

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

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

</Tabs>

`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](/flock/docs/gitops/reference/resources/kafka-topic/) lists every `access` field.
- [Provision SCRAM users](/flock/docs/gitops/how-to/provision-scram-users/) creates the credentials for the principals you grant access.
- Runnable version: [scenarios/05-topic-with-access](https://github.com/monedula-dev/monedula-gitops/tree/main/scenarios/05-topic-with-access)