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
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
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
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
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
Global Admin is the full administrative role used for zone management, cluster assignment, administrative policies, and global product control
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
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
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 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.
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.
A cluster-specific baseline for regular topics, including replication factor and min.insync.replicas.
A short-lived topic profile that can pre-fill retention and delete cleanup policy together with replication defaults.
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.
Administrative views expose usage analytics, successful and failed authentication activity, and configuration/audit information needed for operational review.
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.
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.
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
A short product overview, core principles, key capabilities, access model, and the baseline startup scenario
A step-by-step guide for environment preparation, running the installer, starting the application, and performing post-install verification
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