Unkillable zombie blog

First, some notes about this post

This blog post is partially written by AI. I cleared up the text, added in my own mistakes. I’m not a fan of LLM content, as it is typically AI-slop, however , as this blog received an update in 2015, one in 2017 and 2 updates in 2021 with one of being about migrating a static website (Pelican) to Kubernetes, i thoight it was very fittign that the next post, in 2026 would be partly written by AI.

In fact, it was not just written by AI, but keeping up with the tradition, but done in a massive overkill way using opencode with oh-my-openagent (details in this blog )

Now to the main topic. Back in July 2021 I announced Gafkalo, a CLI tool to manage Confluent Kafka resources using YAML and RBAC. It has come a long way since then.

The project has seen several releases and a lot of commits. It is still actively maintained. What started as a tool to scratch a personal itch has grown into a fairly comprehensive Confluent platform management utility.

Here are some of the major features and improvements that have landed since that initial announcement.

Cluster Link management

The biggest new feature is support for Confluent Cluster Links. You can now create, list, describe, and configure cluster links declaratively from YAML, just like topics and schemas. It includes reconciliation logic, dry-run support for updates, and config diff handling so you can see what will change before applying. Confluent rest-proxy API is used internally. As it hides “sensitive” values , this makes it impossible to compare these with the value in the input YAML. That makes for ugly plans where, these values are always present. I hoped to find these in a topic (like schemas :) ), and bypass these filters , but this does not look to be the storage for this data.

Connector lifecycle management

Connectors were always supported, but now they are fully first-class citizens. You can manage them declaratively in YAML with proper plan and apply workflows, including diff output that shows old versus new configuration values. Gafkalo also detects masked sensitive fields from Confluent Connect, so it does not falsely report drift on hidden password fields.

SOPS integration and secret masking

For teams running Gafkalo in GitOps pipelines, two security features are important. First, SOPS encryption is supported for input YAML files, allowing sensitive connector configuration to be stored encrypted in Git. Second, sensitive keys in output can be masked via configurable regular expressions, keeping secrets out of logs and CI output.

Better CLI ergonomics

A number of quality-of-life improvements make day-to-day use smoother. Bash and ZSH auto-completion is supported. You can create topics and list all topics directly from the command line without writing YAML. Consumer output supports JSON format for piping into other tools, and Kafka record headers are now displayed. Partition reassignment can also be done via CLI.

More authencation protocols supported

Enterprise authentication options expanded significantly. Mutual TLS is now supported for Kafka connections, along with SCRAM SHA-256 and SHA-512. TLS support was also added for the Confluent Metadata Server, enabling RBAC management over secure connections. Most of these are tested using test-containers. One that has been a long-time pain point for me is Kerberos, which is finally tested.

Closing thoughts

Gafkalo remains a single, dependency-free binary that you can drop anywhere and use to manage topics, schemas, RBAC permissions, connectors, and now cluster links. If you are running Confluent platform and want a GitOps-friendly way to manage it, it is worth a look.

Documentation is at https://gafkalo.readthedocs.io/ and the code is on GitHub.

What is Gafkalo?

It is a CLI tool that can primarily be used to manage resources in Confluent platform, using RBAC.

You can provide it with a YAML input definition of Topics, their Key and Value schemas, permissions for any principals and the tool will make the required changes to your cluster.

An example YAML:

topics:
  - name: SKATA.VROMIA.POLY
    partitions: 6
    replication_factor: 1
    # Any topic configs can be added to this key
    configs:
      cleanup.policy: delete
      min.insync.replicas: 1
      retention.ms: 10000000
    key:
      schema: "schema-key.json"
      compatibility: BACKWARD
    value:
      schema: "schema.json"
      compatibility: NONE
  - name: SKATA.VROMIA.LIGO
    partitions: 6
    replication_factor: 3
    configs:
      cleanup.policy: delete
      min.insync.replicas: 1
    key:
      schema: "schema-key.json"
  - name: SKATA1
    partitions: 1
    replication_factor: 1

Having a nice set of topics + schemas is not much useful if nobody can use them. So lets assign some permissions.

Gafkalo currently operates under the idea of giving a set of roles that match a usage pattern. Namely a being a consumer, a producer or (or resourceowner).

For example when assigning consumer_for to a topic, the tool will also create read permissions to the corresponding schema registry subjects, and optionally the consumer group.

Example:

clients:
  # principals must be in the form User:name or Group:name
  # For each principal you can have a consumer_for, producer_for or resourceowner_for
  # and the topics for each of these categories
  - principal: User:poutanaola
    consumer_for:
      # By default we will use PREFIXED.
      # set prefixed: false to set it to LITERAL
      - topic: TOPIC1.
      - topic: TOPIC2.
        prefixed: false
    producer_for:
      - topic: TOPIC1.
    resourceowner_for:
      - topic: TOPIC4.
  - principal: Group:malakes
    consumer_for:
      - topic: TOPIC1.
      - topic: TOPIC2.
    producer_for:
      - topic: TOPIC1.
        strict: false
    groups:
      - name: consumer-produser-
        # if not specified, roles is [DeveloperRead]
        # roles: ["ResourceOwner"]
        # prefixed is true by default but can be disabled like below
        refixed: false

After configuring gafkalo with the required config file (pointing it to bootstrap brokers, schema registry and all required authenticaton you can see a plan of what it would do:

gafkalo plan --config myconfig.yaml

This will produce an output of what operations are going to take place if you run in apply mode.

Once you are satisfied that its going to do the right thing, run in apply (yes, obviously inspired by terrafor..)

gafkalo apply --config myconfig.yaml

You will, again, get a report of what actions were taken.

It is not yet supported to increase replication_factor for topics, but should be easy to implement as re-assignment strategy code is already present..

Debugging tool

Apart from maintaining the state of your cluster, Gafkalo can be a nice debugging tool.

Some functions are:

• consumer
• producer
• schema checker
  • Get a diff between a registered schema and a provided json.
  • Check if a schema is already registered under a subject

As a debugging tool, there are plenty of features to be added still. For example, it will be quite nice to send tombstones manually. Especially when managing some connectors like Debezium it is often required to drop recorded offsets from connectors.

Consumer

Gafkalo can be used as a consumer. It supports reading from multiple topics, setting consumer group, idempotence and resetting partition:offset.

Additionally, it supports pointing it to a Go template file to format records any way you want!

More details in the documentation