Least-privilege connecting principal

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, 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.

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 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 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 explains the warning.