Schema Registry Proxy Govern Your Schema Registry Like You Govern Kafka.
Add authentication, per-subject access controls, and observability to your schema registry. Drop-in proxy, no client code changes.
Why Schema Registries Are a Governance Blind Spot
Organizations have invested heavily in securing Kafka with centralized identity providers, ACLs, and audit trails. The schema registry, which controls the shape of every message in your pipelines, rarely gets the same treatment. The result is accidental breaking changes, security gaps, and compliance exposure that grow with every team you onboard.
No Modern Authentication
Most schema registries are wide open or limited to basic auth. Kafka has mature SASL/OAuth integration with your IdP, but the schema registry has no way to enforce the same policies. Closing the gap without custom engineering isn't straightforward.
No Way to Scope Access to Ownership
There's no mechanism to map schema write permissions to team ownership. It's all-or-nothing access to the entire registry. A single accidental schema change can break every downstream consumer.
No Audit Trail
No centralized logging or tracing for schema registry operations. Compliance teams can't demonstrate governance over data contracts. When something breaks, nobody can answer "what changed?"
JWT/OIDC Authentication
Validates tokens from your existing identity provider (Keycloak, Auth0, Okta, Azure AD) in front of the registry. Use the same IdP you already run for Kafka. No new identity infrastructure to deploy.
Per-Subject Access Controls
Read and Write permissions per schema subject with exact match, wildcard, and prefix matching. Permissions update dynamically via Kafka, so changes take effect without restarts.
Full Observability
Every operation is traced (OpenTelemetry), metered (Prometheus), and logged (structured JSON). Correlate schema changes with downstream impact across your Kafka environment.
Confluent SR API-Compatible
Supports the core schema registry endpoints used by Kafka producers and consumers for serialization and deserialization. Change your schema.registry.url and everything works without code changes.
Dynamic Configuration via Kafka
Permissions are stored in a Kafka topic and applied in real time via KCache. Also supports static in-memory configuration for simpler deployments.
TLS and Backend Security
HTTPS with TLS termination for clients, mTLS or OAuth client credentials for the registry backend. Supports SASL/PLAIN, SCRAM, OAUTHBEARER, and GSSAPI for Kafka connections.
Learn more: Gateway overview · Kafka data security · Deployment guide
How It Works
Three steps from unprotected registry to governed schema operations.
Update schema.registry.url to point at the proxy instead of your registry. No other client changes needed. Existing serializers and deserializers work as-is.
The proxy validates the JWT in the Authorization header against your IdP's JWKS endpoint, extracts the caller identity, and checks permissions against the target schema subject. All of this happens before any request reaches your registry.
Authorized requests are forwarded to your registry backend with the proxy's own credentials. Responses pass through transparently. Every request is traced, metered, and logged.
Upgrading from Confluent Platform pre-8.0?
Confluent Platform 8.0 requires KRaft mode, which is incompatible with the Topic ACL Authorizer many teams relied on for schema-level access control. Upgrading means choosing between staying on an aging platform or purchasing Confluent Enterprise licensing for the Schema Registry Security Plugin.
Conduktor's Schema Registry Proxy gives you a third option: upgrade to CP 8.0+ and keep granular schema access control, without Confluent Enterprise licensing.
Frequently asked questions
Do I need to change my application code?
No. Update schema.registry.url in your Kafka client configuration to point at the proxy. Producers and consumers continue using their existing serializers and deserializers. No code changes, no library swaps.
Which schema registries does the proxy support?
The proxy currently supports Confluent Schema Registry and any registry that implements the same REST API. It forwards requests transparently, so any compatible backend will work.
How are permissions managed?
Permissions can be managed two ways: statically in the proxy's application configuration, or dynamically via a Kafka topic. Dynamic mode uses KCache to consume permission updates and apply them in real time without restarts.
What identity providers are supported?
Any OAuth2/OIDC provider that exposes a JWKS endpoint. This includes Keycloak, Auth0, Okta, Azure AD, and Google. The proxy validates JWTs using the provider's public keys and supports automatic key rotation.
Does this work with Confluent Cloud?
Yes. The proxy can connect to any Confluent Schema Registry instance, including Confluent Cloud, using basic auth or OAuth bearer tokens for the backend connection.
What's the relationship between the Schema Registry Proxy and Conduktor Gateway?
The Schema Registry Proxy is a separate component that does for your schema registry what Gateway does for Kafka brokers: it sits in front of the backend and adds authentication, authorization, and observability. It can be deployed alongside Gateway or independently.
How does this compare to the Confluent Schema Registry Security Plugin?
The Confluent Security Plugin requires Confluent Enterprise licensing and is tightly coupled to Confluent's RBAC system. The Schema Registry Proxy works with any OIDC identity provider, supports dynamic permission management via Kafka, and doesn't require additional Confluent licensing. It's also compatible with Confluent Platform 8.0+ where the Topic ACL Authorizer is no longer available.
Ready to govern your schema registry?
Our team can walk you through a deployment that fits your existing identity provider, Kafka setup, and compliance requirements.