---
title: "Least-privilege connecting principal"
description: "The Kafka ACLs, Schema Registry rights and Confluent RBAC roles that the principal monedula-gitops connects as needs for each kind it manages."
url: https://monedula.dev/flock/docs/gitops/reference/connecting-principal-acls/
---
A super-user needs none of these grants, because it bypasses ACL enforcement. Any other principal needs the rows for the kinds it manages. With the CLI, `diff`, `verify` and `apply` [read live state only for the kinds the loaded manifests declare](/flock/docs/gitops/reference/cli/#cluster-config), so a pipeline that manages only topics needs only the topic rows.

## Topics

For `KafkaTopic`:

| Action | Operation | Resource |
| --- | --- | --- |
| Read live state for `diff`, `verify` and `apply` | `Describe` and `DescribeConfigs` | the topic |
| Create a topic | `Create` | the topic, or the `Cluster` to create any topic |
| Change the topic configuration | `AlterConfigs` | the topic |
| Add partitions | `Alter` | the topic |
| Delete the topic | `Delete` | the topic |

A prefixed ACL covers every topic that follows a naming scheme. `Delete` is needed only for an operator `KafkaTopic` with `deletionPolicy: Delete`: neither the default, `Orphan`, nor the CLI ever deletes a topic.

## ACLs

For `KafkaAccessPolicy` and the `access` block of a `KafkaTopic`:

| Action | Operation | Resource |
| --- | --- | --- |
| List ACLs | `Describe` | `Cluster` |
| Create and delete ACLs | `Alter` | `Cluster` |

The operator lists the cluster's ACLs on every `KafkaTopic` reconcile, with or without an `access` block, so its principal needs `Describe` on `Cluster` even when it manages only topics.

Kafka authorizes the ACL API on the `Cluster` resource only, so a principal that manages any ACL can manage every ACL on the cluster. Limit what monedula-gitops touches through the manifests you give it and, with the operator, a [tenancy policy](/flock/docs/gitops/how-to/enforce-tenancy/).

## Quotas

For `KafkaQuota`:

| Action | Operation | Resource |
| --- | --- | --- |
| List quotas | `DescribeConfigs` | `Cluster` |
| Set and remove quotas | `AlterConfigs` | `Cluster` |

The client-quota API has no per-user, per-client-id or per-IP authorization.

## SCRAM users

For `KafkaUser`:

| Action | Operation | Resource |
| --- | --- | --- |
| List credentials | `Describe` | `Cluster` |
| Create, update and delete a credential | `Alter` | `Cluster` |

There is no per-username authorization either: a principal that may manage one `KafkaUser` may set or rotate the credential of any user name.

## Schema Registry

For the `schema` of a `KafkaTopic`, the registry's own authorizer decides, if one is configured; Kafka ACLs play no part. The identity that `spec.schemaRegistry.auth` or a TLS client certificate gives monedula-gitops needs to read subjects, register schema versions, and read and set the compatibility of the subjects it manages. Your registry's authorization docs name the matching roles or permissions.

## Confluent RBAC

For `KafkaRoleBinding`, and for topic access on a cluster with `accessBackends` that include `rbac`, monedula-gitops lists, adds and removes role bindings through MDS. The MDS principal in `authorization.mds.auth` needs a role that may manage role bindings at the scopes you declare, such as `UserAdmin` or `SecurityAdmin`; the [Confluent RBAC documentation](https://docs.confluent.io/platform/current/security/rbac/index.html) lists what each role permits in your Confluent Platform version.

## Keeping cluster-wide grants on one principal

ACL, quota and SCRAM management each need a grant on the `Cluster`, and Kafka offers nothing narrower. With the CLI, if that is too broad for your threat model, run the pipelines that manage `KafkaAccessPolicy`, topic access, `KafkaQuota` and `KafkaUser` as a dedicated high-trust principal, and the pipelines that manage only topics as a principal with just the topic rows. The operator connects through the [one `KafkaCluster`](/flock/docs/gitops/how-to/configure-the-operator/#resolve-every-kafkacluster-from-one-namespace) that represents each Kafka cluster, so its principal needs the grants of every kind the operator manages there. A principal without super-user rights can also lock itself out of a topic once that topic has ACLs; [Connect to a secured Kafka cluster](/flock/docs/gitops/how-to/connect-to-a-secured-cluster/) explains the warning.