Introducing Schema Registry Proxy

Schema registry governance gets deferred because the tooling isn't there. We built Schema Registry Proxy to change that.

Nicole BouchardNicole Bouchard · March 24, 2026 ·
Introducing Schema Registry Proxy

Govern Your Schema Registry Like You Govern Kafka

We talk to platform teams about Kafka governance all the time. Most of them have done real work: SSO integrated, ACLs configured, audit trails flowing into their SIEM. However, when we ask about schema registry governance, the answer is usually a pause, followed by something like "yeah, that's on the list".

When you're building out Kafka, the schema registry is a utility. You set it up, point your serializers at it, and focus on the harder, more immediate problems such as broker security, access control, observability. The registry doesn't demand attention at first, it just works.

Why schema registry governance gets deferred

Schema registry governance tends to become a problem later in the adoption curve. Early on, you have a small team, a handful of schemas, and everyone knows what everyone else is doing. The registry is a shared tool that nobody thinks about much.

Then the org grows. A developer on one team registers a schema change that breaks consumers on another team. An engineer with broad access deletes a subject they thought was unused. A compliance review asks how you govern data contracts and nobody has a good answer.

By the time these things happen, you've got a lot competing for your attention. The schema registry problem is real, but it's rarely the most urgent thing in the queue, so it gets deferred.

Limited tooling, no integration

Part of the reason this stays on the back burner is that the tools to address it are thin.

Most schema registries were designed as serialization utilities, not as governed infrastructure. Auth options are typically basic auth or nothing. Fine-grained access control, the kind that's been standard on Kafka brokers for years, generally requires additional licensing, a different registry product entirely, or custom engineering. There's no widely available, registry-agnostic governance layer you can drop in.

It's also an integration problem. Your Kafka governance stack doesn't extend to the schema registry. It's a separate system with its own auth, its own tooling, its own operational workflow. Even when teams recognize the gap, closing it means building and maintaining something outside the stack they've already invested in.

We kept hearing about this in customer conversations. Teams that had done the work to lock down Kafka would hit the same wall: the schema registry was wide open, and there wasn't an obvious path to fix it without significant engineering effort or a licensing change.

What actually goes wrong

The most common incident we hear about is a schema change that breaks downstream consumers. Someone registers a new version, maybe they add a required field or change a type, and consumers that depend on the old format start failing.

In a governed system, you'd trace that back quickly. Who changed the schema, when, what was the previous version. But without an audit trail on the registry, the investigation starts from scratch. Teams check git history, Slack threads, deployment logs, anything that might explain what happened. It can take hours to connect a production incident to a schema change.

The second kind of pain is quieter but more persistent. Security and compliance teams flag the schema registry during reviews. There's no SSO integration, no role-based access, no logging. The registry doesn't meet the same governance standard as the rest of the Kafka infrastructure. This creates audit findings that somebody has to answer for, even if nothing has gone wrong yet.

For some of our customers, the Confluent Platform 8.0 upgrade added urgency. KRaft mode broke the Topic ACL Authorizer that some teams had been using as a workaround for schema-level access control. They came to us looking for a path forward that didn't require additional Confluent Enterprise licensing. But the underlying problem predates that migration. It's the same gap, just made more visible by an infrastructure change.

Schema Registry Proxy: what we built to close the gap

Similar to our Gateway product, we've built a Schema Registry Proxy to sit between your Kafka clients and your schema registry and adds the three things that were missing.

First, authentication. The proxy validates JWT/OIDC tokens from your existing identity provider (Keycloak, Auth0, Okta, Azure AD, or anything with a JWKS endpoint). Your teams authenticate with the same IdP they already use for Kafka. No new identity infrastructure to deploy.

Second, authorization. Read and Write permissions per schema subject, with support for exact match, wildcards, and prefix matching. You can give the payments team write access to payments-* without giving them access to everything else. Permissions are stored in a Kafka topic and update in real time, so there are no proxy restarts when access changes.

Third, observability. Every operation gets an OpenTelemetry trace, a Prometheus metric, and a structured log entry. When a schema change causes a downstream incident, you can trace it back to the specific operation, the authenticated caller, and the exact time it happened.

We built it as a proxy because it's the only approach that works without changing your clients, your registry, or your schemas. You update one configuration property, schema.registry.url, and the governance layer is in place. Your existing serializers and deserializers work as-is.

It's not a schema management platform. It doesn't handle schema evolution strategy or compatibility rules; your registry still does that. It's focused on the governance gap: making sure the right people have the right access, and that you have a record of everything that happens.

If this sounds familiar

If your schema registry is the thing that keeps getting deferred to next quarter, we'd like to help.