Services¶
If you have security on your cluster, you can use kafka-gitops to manage ACLs. Kafka GitOps automatically builds the necessary ACLs for most common use cases.
Application Example¶
A basic example shown below defines one topic, test-topic, and one service, my-application.
The service my-application both consumes from and produces to test-topic. This will generate the necessary ACLs for my-application to do this.
Note
If you use Confluent Cloud, omit the principal field.
topics:
test-topic:
partitions: 6
replication: 1
services:
my-application:
type: application
principal: User:myapp
consumes:
- test-topic
produces:
- test-topic
Behind the scenes, this will generate three ACLs:
READfor topictest-topicWRITEfor topictest-topicREADfor consumer groupmy-application
Group ID¶
The group.id used for consumer ACLs defaults to the service name. You can override this by specifying the group-id property, as shown below:
services:
my-application:
type: application
principal: User:myapp
group-id: my-application-service
consumes:
- test-topic
produces:
- test-topic
This allows your consumer group to access Kafka using my-application-service as the group.id.
Kafka Streams Example¶
A basic example shown below defines one topic, test-topic, and one Kafka Streams application, my-stream.
The service my-stream both consumes from and produces to test-topic. This will generate the necessary ACLs for my-stream to do this.
topics:
test-topic:
partitions: 6
replication: 1
services:
my-stream:
type: kafka-streams
principal: User:mystream
consumes:
- test-topic
produces:
- test-topic
Behind the scenes, this generates ACLs such as:
READfor topictest-topicWRITEfor topictest-topicREADfor consumer groupmy-stream- Various ACLs for Kafka streams internal topic management
Application ID¶
The application.id used for streams ACLs defaults to the service name. You can override this by specifying the application-id property, as shown below:
services:
my-stream:
type: kafka-streams
principal: User:mystream
application-id: my-stream-application
consumes:
- test-topic
produces:
- test-topic
This allows your Streams application to access Kafka using my-stream-application as the application.id.
Kafka Connect Example¶
A basic example which defines one Kafka Connect cluster that has one connector running.
topics:
connect-configs-my-connect-cluster:
partitions: 1
replication: 1
configs:
cleanup.policy: compact
connect-offsets-my-connect-cluster:
partitions: 25
replication: 1
configs:
cleanup.policy: compact
connect-status-my-connect-cluster:
partitions: 5
replication: 1
configs:
cleanup.policy: compact
rabbitmq-data:
partitions: 6
replication: 1
services:
my-connect-cluster:
type: kafka-connect
principal: User:myconnectcluster
connectors:
rabbitmq-sink:
consumes:
- rabbitmq-data
Behind the scenes, this generates ACLs such as:
READfor topicrabbitmq-dataREADfor the consumer groupconnect-rabbitmq-sinkREADandWRITEfor the internal kafka connect topicsREADfor the consumer groupmy-connect-cluster
Storage Topics¶
By default, kafka-gitops generates ACLs for the internal storage topics following this format:
connect-configs-{service-name}connect-offsets-{service-name}connect-status-{service-name}
You can specify custom internal storage topics using the storage-topics property:
services:
my-connect-cluster:
type: kafka-connect
principal: User:myconnectcluster
storage-topics:
config: custom-config-topic
offset: custom-offset-topic
status: custom-status-topic
connectors:
rabbitmq-sink:
consumes:
- rabbitmq-data
Group ID¶
The group.id used for the connect cluster ACLs defaults to the service name. You can override this by specifying the group-id property, as shown below:
services:
my-connect-cluster:
type: kafka-connect
principal: User:myconnectcluster
group-id: kafka-connect-cluster
connectors:
rabbitmq-sink:
consumes:
- rabbitmq-data
This allows your Connect cluster to access Kafka using kafka-connect-cluster as the group.id.
Note
The group-id setting only affects the Connect cluster group.id, not any sink connector group IDs.