Documentation

The public documentation stays at the product and deployment level: clear enough for evaluation, pilot, and rollout, while making the Kerberos, SASL/GSSAPI, RBAC, and production use model explicit for real Apache Kafka environments

  • Product overview KafkaKombat is a Kerberos-first web UI for working with one or multiple Kafka clusters that can be grouped into access zones.
  • Key workflows Cluster, broker, topic, and consumer group browsing; lag analysis; problems view; message browsing; controlled offset reset; partition increase; topic creation profiles; and topic clone, recreate, or clear workflows.
  • Access model Global Admin and Zone Admin roles are supported, together with a zone-based access model and application RBAC layered on top of infrastructure access control.
  • Message handling The product supports a protobuf descriptors registry, a protobuf-aware read path, topic-level masking policy, server-side masking, and safe rendering of protected payloads.
  • Service data PostgreSQL is used to store service data and operational application configuration.

Kerberos, SASL/GSSAPI, and user-ticket execution

KafkaKombat is designed for Apache Kafka environments where Kerberos is part of the real runtime model rather than a checkbox in a demo configuration. This includes SASL/GSSAPI-based Kafka client authentication, krb5.conf, ticket cache handling, and the operational expectation that security rules should remain visible in the UI path instead of being bypassed by a generic shared identity

  • Kerberos is the authentication base for the target class of environments supported by the product.
  • SASL/GSSAPI is part of the normal Kafka client model for Kerberos-protected Apache Kafka clusters.
  • User-driven Kafka operations are executed with the user’s own Kerberos ticket rather than a shared service identity for normal UI actions.
  • Service principal and keytab are reserved for backend and background functions that do not operate on behalf of a specific interactive user.

Production status and Apache Kafka compatibility

Used in real environments

KafkaKombat is already used in development and production environments by multiple internal teams working with Kerberos-protected Apache Kafka clusters and a multi-cluster operational setup

Tested compatibility

KafkaKombat has been tested with Apache Kafka versions 3.0.0 through 4.2.0. If support for additional Kafka versions is required, feedback can be sent through the contact page or through GitHub issues

Roles, LDAP-backed RBAC, and access zones

Global Admin

Global Admin is the full administrative role used for zone management, cluster assignment, administrative policies, and global product control

Zone Admin

Zone Admin is an administrative role limited to the assigned access zones and their clusters. This keeps operational power close to the owning team without making all administration global

LDAP-backed RBAC

Infrastructure access is not treated as enough on its own. KafkaKombat adds application RBAC, zone-based access, and role decisions that can follow LDAP groups and the application catalog model

Controlled operations and per-cluster policies

Policy modes

Dangerous operations are governed per cluster. A supported operation can be Disabled, available as Self-service, or require an Approval workflow. The policy is resolved on the server side before execution.

Offset reset

Offset reset is available for inactive consumer groups and supports latest, earliest, timestamp-based, and exact per-partition targets. A preview shows affected partitions and the expected skipped or replayed messages before execution. Self-service mode still requires explicit confirmation; approval mode routes the request to another authorized user.

Increase partitions

Partition count increases use the same cluster-level policy model. The UI reviews the current and target partition count before execution, and approval can be required for environments where this irreversible Kafka operation must be separated from the requester.

Topic creation profiles

Normal

A cluster-specific baseline for regular topics, including replication factor and min.insync.replicas.

Temporary

A short-lived topic profile that can pre-fill retention and delete cleanup policy together with replication defaults.

Compacted

A profile for compacted service topics with cluster-specific replication and cleanup.policy=compact defaults.

Profiles are suggestions, not locks: they pre-fill recommended values in the Create Topic form and the user can adjust them before creating the topic.

Operational visibility and degraded read paths

Usage and audit

Administrative views expose usage analytics, successful and failed authentication activity, and configuration/audit information needed for operational review.

Logs and background jobs

Admins can inspect application/service logs, list and download managed application, bootstrap, service, and GC log files, and review background job health with last run, last success, error, and duration information.

Partial Kafka availability

Consumer and lag views are designed to keep available data visible when one broker request fails. The UI reports partial results explicitly instead of turning every partial broker failure into a complete page failure.

Message browsing, masking, and protobuf-aware read paths

KafkaKombat is not limited to generic topic listing. The product includes safe message browsing for operational workflows, topic-level decode configuration, protobuf-aware rendering, and topic-level masking policies that are enforced server-side rather than left as a cosmetic frontend preference

Documents shipped with the distribution

README

A short product overview, core principles, key capabilities, access model, and the baseline startup scenario

INSTALL

A step-by-step guide for environment preparation, running the installer, starting the application, and performing post-install verification

What the public documentation is and is not

The website does not try to replace internal engineering documentation. It gives the public-facing product outline: what the project is for, which Kerberos and SASL/GSSAPI model it expects, how RBAC and zones work at a high level, and which workflows it covers. Deep implementation details remain part of the distribution and of environment-specific adaptation