Schema Registry Proxy
Authorize. Audit. Govern.
A Kafka-aware proxy that adds access control, auditing, and policy enforcement to the schema registry you already run. No client changes.
Let's protect the schema registry like we protect Kafka.
We built the Schema Registry Proxy so every schema operation is authorized and on the record, on the registry you already run, with the identities you already manage. Drop in, and point to any provider.
Authorization out of the box
Confluent's free Schema Registry doesn't have authorization: anyone with access can change any schema. The unlock? Confluent Platform, often $100k+ a year. Open source options: coarse roles or password files. Either way: the burden is on you.
Per-subject Read and Write permissions, checked on every request, on the registry you already run. No platform license.
Put every operation on the record
Out of the box, schema registry auditing doesn't exist. From vendors, it's another paid tier. A schema changes, consumers break, and there is no record of who did it, when, or why. Compliance asks for evidence and there is none to give.
Every operation is traced end to end, every denial is logged with who tried what, and every permission change is recorded.
Inherit your Kafka permissions
The usual fix is nginx or an API gateway in front of the registry. Sensible, but it guards routes, not subjects. It can't inherit the permissions you already manage in Kafka or Console, and wiring in your identity provider is config someone owns forever.
Permissions come from where they live: your Kafka ACLs or federated ownership in Console. OIDC and key rotation built in.
Grant · Enforce · Observe.
Give each application its subjects, let the proxy check every call, and keep a record of everything. Permissions come from Console or the Kafka ACLs you already manage.
apiVersion: self-serve/v1
kind: ApplicationInstance
metadata:
application: "payments"
name: "payments-prod"
spec:
cluster: "prod-kafka"
serviceAccount: "payments-service"
resources:
- type: TOPIC
patternType: PREFIXED
name: "payments"
- type: SUBJECT
patternType: PREFIXED
name: "payments"
$ conduktor apply -f payments-prod.yaml
ApplicationInstance/payments-prod: Created$ kafka-acls --bootstrap-server kafka:9092 \
--command-config admin.properties \
--add --allow-principal User:payments-service \
--operation WRITE --operation READ \
--topic payments --resource-pattern-type PREFIXED
Adding ACLs for resource ResourcePattern(resourceType=TOPIC,
name=payments, patternType=PREFIXED):
(principal=User:payments-service, host=*,
operation=WRITE, permissionType=ALLOW)
(principal=User:payments-service, host=*,
operation=READ, permissionType=ALLOW)
# subjects inherit their topic's ACLs:
# subject payments-value → topic "payments"# payments-service registers a new version
$ curl -X POST http://srp:8080/subjects/payments-value/versions \
-H "Authorization: Bearer $PAYMENTS_TOKEN" \
-H "Content-Type: application/vnd.schemaregistry.v1+json" \
-d @new-schema.json
{"id": 7}
# analytics-service, never granted payments-*, tries the same
HTTP/1.1 403 Forbidden
{
"error_code": 403,
"message": "Forbidden: Service account
'analytics-service' is not authorized
to Write resource 'payments-value'"
}POST /subjects/{subject}/versions 38ms
│ http.method: POST
│ http.target: /subjects/payments-value/versions
│ http.status_code: 200
│
└─ HTTP POST schema-registry:8081 31ms
# one trace per operation: proxy overhead,
# backend latency, and status on every span{
"@timestamp": "2026-06-05T01:12:09.482Z",
"level": "WARN",
"service": "schema-registry-proxy",
"message": "Authorization failed: Service account
'analytics-service' is not authorized
to Write resource 'payments-value'"
}
{
"@timestamp": "2026-06-05T01:14:51.077Z",
"level": "WARN",
"service": "schema-registry-proxy",
"message": "Authentication failed: JWT validation
failed: Expired JWT"
}The same registry, locked down.
Put the proxy in front of the schema registry you already run.
Nothing about your applications changes. Everything about who can touch schemas does.
Before Schema Registry Proxy
Some teams run the registry wide open. Most front it with a generic HTTP proxy that checks routes and tokens. Both guard the door, not the schemas behind it.
After Schema Registry Proxy
Every request is authenticated against your identity provider and checked against per-subject permissions. Add Conduktor Console for federated ownership and human schema management.
Built to drop into your stack. Works with any Confluent-API-compatible schema registry, including Confluent Cloud.
Per-subject permissions
Read and Write per subject, with exact, prefix, and wildcard matching. Checked on every request, before anything reaches your registry.
Your identity provider
Keycloak, Auth0, Okta, Microsoft Entra ID, or any OAuth2/OIDC provider with a JWKS endpoint. Automatic key rotation included.
Kafka-native permissions
Delivered through a Kafka topic from Console and applied in seconds, or read from your existing ACLs. No restarts, no new datastore.
Fails closed
If a permission can't be verified, the request is denied. Errors and timeouts never fail open.
Traces, logs, and metrics
One OpenTelemetry trace per operation, every denial logged with the caller's identity, and Prometheus metrics out of the box.
Runs where Kafka runs
A single container, on-premises, in the cloud, or air-gapped. Alongside Gateway or on its own.
Resource policies · next
Set schema standards once: compatibility floors, format requirements, and naming conventions, enforced at registration for every team and tool.
Rate limiting · next
Per-principal request limits, so one bad deploy in a restart loop can't flood the registry every other team depends on.
Four Ways to Run a Schema Registry
Most teams are in one of the first three columns today.
| No protection | Generic HTTP proxy | Confluent Platform RBAC | Schema Registry Proxy | |
|---|---|---|---|---|
| Authorization | None | Route allowlists | Per-subject RBAC | ✓ Per-subject, prefix and wildcard |
| Understands | Nothing | URLs and methods | Subjects | ✓ Subjects and your Kafka identities |
| Identity | None | Separate auth config | Confluent's identity plane | ✓ The same accounts as your Kafka |
| Works with | Any registry | Any registry | Confluent Platform only | ✓ Any Confluent-API registry |
| Licensing | Free | Engineering time | Full platform license | ✓ Standalone |
| Maintenance | None | Your team | Confluent | ✓ Conduktor |
The Topic ACL Authorizer is deprecated. Your ACLs don't have to be.
For years, the Topic ACL Authorizer let topic owners govern their own subjects. Confluent Platform 8.0 deprecates it, which puts every team that relies on it on a migration clock toward Confluent RBAC, an enterprise-license feature.
There's a third option. The proxy's standalone mode is modeled after the authorizer: the same topic ACLs keep governing the same subjects. Point schema.registry.url at the proxy and upgrade on your own schedule. No RBAC migration, no platform license.
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.
How are permissions managed?
Two ways. Through Conduktor Console, where subjects join your federated ownership model and changes apply in seconds via Kafka. Or standalone, where the proxy reads the Kafka topic ACLs you already manage. Console is not required.
Can it replace the Confluent Topic ACL Authorizer?
Yes. Standalone mode is modeled after it: the same topic ACLs govern the same subjects, with the same semantics. It works on Confluent Platform 8.0 and beyond, where the authorizer is deprecated. The deployment guide covers the exact mapping.
Which schema registries does the proxy support?
Confluent Schema Registry and any registry that implements the same REST API, including Confluent Cloud.
What about deletes and compatibility changes?
They can't reach the registry through the proxy. Applications get only the endpoints they need to produce and consume, nothing destructive. Schema management happens through Console, where it's governed and recorded.
What's the relationship between the Schema Registry Proxy and Conduktor Gateway?
The same philosophy at a different layer. Gateway sits in front of your Kafka clusters. The Schema Registry Proxy sits in front of your registry. Both enforce who can do what without touching clients, and they share the same identities. Deploy them together or independently.
Ready to govern your schema registry?
Our team can walk you through a deployment that fits your identity provider, your Kafka setup, and your compliance requirements.