# SBB: One Interface Across 11 Kafka Clusters

> "Console is a great way to get visibility and overview over all clusters, without being forced to use the Kafka admin CLIs." - Maciej Raciborski, Technical Product Owner, Kafka + Messaging, SBB

## 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.

- **100** — dev teams manage their Kafka objects via Conduktor
- **300** — engineers using it monthly
- **11** — Kafka clusters, one console
- **8k** — topics browsable in one place
- **SSO** — access replaces shared credentials

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](https://www.conduktor.io/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](https://www.conduktor.io/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.

![Two paths into SBB's Kafka: application owners, QA, and analysts sign in to Conduktor Console to manage Kafka resources, with Entra ID groups mapped to Conduktor RBAC, while application developers declare resources in Git for SBB's own operator and API to provision.](https://www.conduktor.io/assets/customer-stories/sbb-platform-layers.svg)

### 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.

> "When you log in, you can access your own Kafka topics, and you're not allowed to see other teams' topics." - Maciej Raciborski

![SBB's access model: an Entra ID group maps to a role, which scopes each user to their own namespace-prefixed Kafka resources, or, for Kafka platform admins, to the whole cluster.](https://www.conduktor.io/assets/customer-stories/sbb-access-model.webp)

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.

![SBB's Kafka operator reconciles developer-declared custom resources against its Kafka Automation API, authenticating through Microsoft Entra ID.](https://www.conduktor.io/assets/customer-stories/sbb-gitops-operator.png)

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.

> "As soon as we see that something is wrong, we often go straight to Console." - Maciej Raciborski

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.

> "We think Conduktor and the Console are the best on the market." - Maciej Raciborski

## 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](https://www.conduktor.io/gateway) in front of the clusters so applications connect to a stable endpoint and never see which cloud is behind it.

> "We plan to hide our real Kafka clusters behind a proxy, so when we move data between cloud providers, the applications won't even notice." - Maciej Raciborski

## Frequently Asked Questions

**How does SBB run Kafka across 11 clusters with one view?**

SBB runs 11 Kafka clusters carrying roughly 8,000 topics, across an on-premise Swiss Cloud, AWS, and Confluent Cloud for internet-facing exchange with partners. 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.

**How does SBB give each team access to only its own Kafka topics?**

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. Teams declare their topics, users, and ACLs in Git, and an in-house operator applies them through a central REST API.

**What did Conduktor Console replace at SBB?**

Larger teams replaced free browser UIs with Conduktor for SSO-backed, per-team access. The free browser UIs could browse topics, but they had no multi-tenancy and could not authenticate against Microsoft Entra ID. Where teams once shared technical Kafka users, every action now traces to a named Entra ID identity scoped to that team's own topics.

## Related Customer Stories

- [Swiss Post: 5x Kafka Growth with 800 Users](https://www.conduktor.io/customer-stories/how-swiss-post-governs-democratizes-kafka-usage) — **Transport & Logistics** · 60 → 300+ apps. "RBAC was the turning point for our compliance."
- [CDC Informatique: 4x Kafka Growth, Flat Team](https://www.conduktor.io/customer-stories/cdc-informatique-governed-kafka-self-service) — **Financial Services** · 40 → 160 apps. "A good sign, for us, is that we don't hear much about Kafka."
- [Investment Fund: AI-Assisted Kafka Rightsizing](https://www.conduktor.io/customer-stories/investment-fund-kafka-rightsizing-for-ai) — **Financial Services** · 50+ TB cluster. "I did the whole rightsizing almost 100% with Claude and the Conduktor MCP."