SBB: 300 Engineers, 100 Apps, One Kafka Interface

Executive Summary

SBB, the Swiss Federal Railways, runs application-to-application messaging on Kafka for the whole company, so that a reliable streaming infrastructure is provided to various digital solutions and group divisions. What started in 2018 as one integration project, replacing a legacy messaging system, grew into a shared platform spanning dozens of teams. Today it runs on 11 Kafka clusters carrying roughly 8,000 topics, across an on-premise Swiss Cloud, AWS, and Confluent Cloud for internet-facing exchange with partners.

As Kafka spread to hundreds of developers, SBB needed one place where every team could see and operate its own Kafka resources. The browser UIs already in use offered no multi-tenancy and no Entra ID sign-in, and building one in-house was not worth the upkeep. So SBB chose Conduktor Console as its single pane of glass. Conduktor's RBAC maps SBB's Entra ID groups to per-team permissions, so a developer signs in through SSO and sees only their own team's topics, consumer groups, and schemas. Around 300 engineers do this across 100 Kafka applications and 11 clusters. Behind those applications are the systems that move passengers, run the rail control network, and keep the timetable honest.

Challenges

Kafka had become shared infrastructure for the whole railway, and most of the people who now needed it were not Kafka administrators. The unsolved problem was giving each team safe access to its own corner of the Kafka environment.

• Visibility and troubleshooting required the Kafka CLI. Kafka spread across SBB's "digital solutions", each with its own development teams and Kafka applications. For the developers, QA, and analysts who now needed it, inspecting a topic or debugging a consumer group meant the Kafka admin CLIs and shell scripts. Those were slow, unintuitive, and demanded a fluency in Kafka internals they had no reason to build.
• No UI could do multi-tenancy or SSO, and building one was costly. The free browser UIs in use could browse topics, but they had no multi-tenancy, so they could not show each team only its own topics. They also could not authenticate against Microsoft Entra ID. Wrapping one in SBB's own authentication and authorization meant owning identity integration and ongoing maintenance across 11 clusters and thousands of topics. That was a lot of upkeep for a tool that was not SBB's core job.
• The fallback was shared credentials. Without per-team access, teams authenticated with shared technical Kafka users. For a state-owned operator, anonymous shared accounts are a security and governance risk, not just an audit gap.

Solution

SBB already provisioned Kafka through its own GitOps pipeline. What it lacked was one place where every team could see and manage their own Kafka objects safely.

One console across every cluster and cloud

Conduktor Console connects to all 11 clusters across every environment, so developers and operators work from one interface. They browse and filter topics, read messages, confirm producers match their schema, and debug or reset consumer groups, without dropping to the CLI.

Multi-tenant access through Conduktor's RBAC

SBB's identity already lives in Microsoft Entra ID, where each Kafka application is tied to a group that controls which topics its team can access. Conduktor's RBAC maps those same groups to Conduktor groups. A developer signs in with their corporate identity and inherits exactly the permissions their group already has. In the Console, each team browses, produces to, and manages only its own topics, consumer groups, and schemas.

SBB provisions Kafka as code: teams declare their topics, users, and ACLs in Git, and an in-house operator applies them through a central REST API.

That is what moved the larger teams: once a team of ten or more needed to manage who could touch which topics, the free UIs could not, and Conduktor could.

The tool the team reaches for during incidents

When an alert fires from SBB's monitoring, the team goes straight to Console to see what's happening inside a topic, a consumer group, or the schema registry.

Thanks to SBB's own engineering, incidents are rare. When one does hit, a single interface across every cluster gives the team the overview without the context switching the CLI demands.

Results

• One interface across 11 Kafka clusters. Roughly 8,000 topics through a single pane of glass, for developers, QA, and analysts across every digital solution.
• Access traceable to a person. Where teams once shared technical Kafka users, every action now traces to a named Entra ID identity scoped to that team's own topics, instead of anonymous shared accounts.
• Free tools and a DIY build, ruled out. Larger teams replaced free browser UIs with Conduktor for SSO-backed, per-team access. SBB kept its engineering time on its own business use cases, rather than the upkeep of an internal UI.

What's next: a proxy for painless cloud migration

The new recurring pain at SBB isn't scale. Rather, it's movement. Migrating between cloud providers every couple of years means every team reconfiguring its clients and redeploying. The next step is to put a Kafka proxy in front of the clusters so applications connect to a stable endpoint and never see which cloud is behind it.

Frequently Asked Questions