Schema Registry Proxy
Authorize. Audit. Govern.
A schema-registry-aware proxy that adds access control, auditing, and policy enforcement to the schema registry you already run. Point your clients at it. No code 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.
Speaks schema, not just HTTP
The usual fix is nginx or an API gateway in front of the registry. Sensible, but it guards routes and methods, not subjects. It can't tell a new version from a destructive overwrite, because it has no idea what a subject or a schema is.
The proxy speaks the schema registry's own API. It reasons about subjects, versions, and compatibility, so every rule is expressed in the registry's own terms.
Authorization out of the box
Open-source registries give you coarse roles or a password file, and no per-subject control. Confluent's answer is Confluent Platform RBAC, often $100k+ a year. Either way, anyone with access can change any schema, and the burden is on you.
Per-subject read and write permissions, checked on every request, on the registry you already run. And they come from where they already live: your Kafka ACLs or federated ownership in Console. 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.
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 registry that implements the Confluent Schema Registry API, including Confluent Cloud, Apicurio, and Karapace.
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 | ✓ OIDC / OAuth2, the same accounts as your Kafka |
| Works with | Any registry | Any registry | Confluent Platform only | ✓ Any registry with the Confluent SR API |
| 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.
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?
Schemas get managed two ways. People evolve them (new versions, compatibility changes, and deletes) through a governed workflow like Console. Applications only need to produce and consume against schemas that already exist, so the proxy gives them exactly those endpoints and nothing destructive. It also closes a common gap: by default a client auto-registers a schema the first time it produces, which pushes validation to the worst moment, a go-live hours after deploy. Provisioning schemas ahead of time and blocking runtime registration moves that feedback loop earlier.
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.