When my mate described what the operations team needed, I suggested starting with Keycloak as the identity layer, after trying to get a gist of how the whole idea would work, and then integrating the interfaces one at a time. The practical question was straightforward: how can support teams inspect Kafka safely without giving everyone administrator access?

Start with the work people need to do

The idea came from the very initial requirements for Krate, but it wasn't understood well: single sign-on for the web interfaces, user management available even without a company identity provider (fallback), and useful visibility into the observability metrics for support teams. L1 and L2 support should be able to inspect graphs, consumer lag, and metrics through a browser. Routine investigation should not require logging into a server and running commands (of course!!).

Creating topics or producing messages is a different ball game. With Kafka, if these actions are not controlled, these can affect applications and data, so access should belong to the appropriate administrators.

That distinction shaped the security work. The starting point was a set of operational needs. Keycloak became the central identity layer because it could support local accounts and integration with an external identity provider while giving applications a consistent sign-in mechanism (honestly, I had not touch Keycloak in 3 years or so and my mind was crawling helplessly trying to piece things together).

Authentication and authorization answer different questions

Authentication asks: who is signing in? A password, a second factor, or an existing company session helps establish identity.

Authorization asks: what may that person do? Successfully signing in should not automatically grant permission to create a topic, change a configuration, or reset consumer offsets.

Role-based access control, usually shortened to RBAC, groups permissions around responsibilities, that's the goal of authorization. A Viewer can inspect the information needed for investigation. An Administrator can perform changes within the application’s administrative scope.

Kafbat is the Kafka web interface used by Krate. In its Keycloak-backed integration, realm groups map to application roles. A realm is Keycloak’s boundary for managing users, groups, and application clients. Keycloak supplies identity and group information; Kafbat enforces the corresponding permissions on its API endpoints. Hiding a button alone would leave the underlying action exposed to someone who calls the API directly (well, there are some of us who are curious enough to "Inspect").

The current Viewer role can inspect cluster information, topic details, metrics, and consumer lag. It cannot create topics, produce or delete messages, or reset offsets. Reading message payloads is also disabled by default and requires a deliberate site-level opt-in. These boundaries are documented in the Krate access guide.

Where Keycloak fits

An identity provider, or IdP, handles authentication and supplies identity information to applications. Keycloak can perform that job itself using locally managed accounts. It can also act as an identity broker, connecting applications to another provider.

With local accounts, users authenticate through Keycloak. With company SSO, Keycloak redirects the sign-in to the enterprise provider and processes the result before returning the user to the application. The application continues to trust Keycloak as its identity issuer. Keycloak documents these capabilities in its server administration guide.

Krate’s current enterprise integration targets PingFederate through OpenID Connect. This keeps the company’s existing authentication and MFA responsibility with its IdP. The integration maps approved company groups to Krate’s Viewer and Administrator groups.

For operations, the benefit is a common identity foundation that can be reused as more interfaces are integrated. Permissions still need to be configured and tested in each application. An application administrator also does not automatically become a Keycloak administrator or gain access to the host operating system.

Local accounts and emergency access

What happens when an installation has no external identity provider?

Keycloak can manage its users locally. Krate provides account-management operations, and users created through its local-user command must change their temporary password and set up time-based one-time passwords (TOTP) at first login. This supports deployments that need named users and roles without depending on company SSO.

An enterprise deployment raises another question: what happens if its external provider is unavailable?

Krate documents an explicit break-glass path for a pre-existing local Keycloak account. The normal sign-in route still redirects to PingFederate. An operator deliberately selects the local authentication path, then authenticates with that account and its configured factors. The account’s realm groups still determine its application permissions. See the local emergency-access procedure.

This needs operational governance: decide who holds emergency access, protect the credentials, test the procedure, and review its use. An IdP outage must not silently give ordinary users an easier login or broader permissions. The local path also depends on Keycloak and its database being available, so their recovery procedures remain important.

Security includes the surrounding services

A login screen is only one part of the boundary. The identity service needs protected storage, restricted administrative access, backups, and a way to rotate credentials.

Krate’s identity foundation includes PostgreSQL-backed persistence, encrypted database connections, a private identity network, and backup and recovery operations. Kafbat and the public Keycloak realm endpoints are reached through an HTTPS proxy. The proxy does not expose Keycloak’s admin console or master realm; operators manage Keycloak from the installation host. These responsibilities are described in the identity foundation guide.

The broader goal is browser-based operational visibility across Kafka and monitoring. Integrating Grafana and Perses with the same realm extends that approach, but each service has its own sessions, permissions, and failure cases to validate.

What is implemented and what remains

As of October 14, 2026, the identity foundation, Kafbat role integration, and enterprise-brokering code are merged. The broker acceptance tests use a stand-in OpenID Connect provider; a real company PingFederate deployment still needs site-specific acceptance.

Grafana, Perses, and monitoring-hardening work is all in progress at this stage. It contains implementation and focused test results, but formal acceptance remains open. Validation of the complete monitoring integration is still ongoing.

Kafka producer and consumer authentication is a separate security boundary, which we have not yet tinker with. Securing the web interfaces does not authenticate every application connecting to a broker. Short-lived credentials and secrets vault are further ideas to evaluate.

The practical objective is clear: give people enough visibility to investigate, reserve changes for the right roles, and make recovery access an explicit, testable procedure.