# 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. [Book a Demo](https://www.conduktor.io/contact/demo) [Download Solution Brief](https://www.conduktor.io/assets/pdfs/use-cases/schema-registry-proxy.pdf) ## 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. 01 · **access** 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. With the proxy Per-subject **Read and Write permissions**, checked on every request, on the registry you already run. No platform license. 02 · **audit** 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. With the proxy Every operation is **traced end to end**, every denial is logged with who tried what, and every permission change is recorded. 03 · **identity** 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. With the proxy **Permissions come from where they live**: your Kafka ACLs or [federated ownership](https://www.conduktor.io/console#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. 01 · grantGive each app its subjectsThrough federated ownership in Console, where applications own their subjects like they own their topics. Or standalone, on the Kafka ACLs you already operate. 02 · enforceEvery request checkedThe JWT is verified against your identity provider, the permission is checked against the subject, and only then is the call forwarded. Denied calls never reach the registry. 03 · observeKnow who did whatA trace for every operation and a log line for every denial, with the caller's identity. OpenTelemetry and Prometheus out of the box. From Console With Kafka ACLs 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'" } Trace Denial log 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. **Neither setup knows what a subject is**, or who owns it. After Schema Registry Proxy Every request is authenticated against your identity provider and checked against per-subject permissions. Add [Conduktor Console](https://www.conduktor.io/console) for federated ownership and human schema management. **The proxy knows both**, on every request. Capabilities Built to drop into your stack. Works with any Confluent-API-compatible schema registry, including Confluent Cloud. Per-subject permissionsRead and Write per subject, with exact, prefix, and wildcard matching. Checked on every request, before anything reaches your registry. Your identity providerKeycloak, Auth0, Okta, Microsoft Entra ID, or any OAuth2/OIDC provider with a JWKS endpoint. Automatic key rotation included. Kafka-native permissionsDelivered through a Kafka topic from Console and applied in seconds, or read from your existing ACLs. No restarts, no new datastore. Fails closedIf a permission can't be verified, the request is denied. Errors and timeouts never fail open. Traces, logs, and metricsOne OpenTelemetry trace per operation, every denial logged with the caller's identity, and Prometheus metrics out of the box. Runs where Kafka runsA single container, on-premises, in the cloud, or air-gapped. Alongside Gateway or on its own. Resource policies · nextSet schema standards once: compatibility floors, format requirements, and naming conventions, enforced at registration for every team and tool. Rate limiting · nextPer-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 | Note for Confluent Customers 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](https://docs.conduktor.io/guide/conduktor-in-production/deploy-artifacts/deploy-schema-registry-proxy) 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. [Book a Demo](https://www.conduktor.io/contact/demo) [Download Solution Brief](https://www.conduktor.io/assets/pdfs/use-cases/schema-registry-proxy.pdf) ## Read more customer stories - [Bitvavo: DORA & MiCA Compliance](https://www.conduktor.io/customer-stories/bitvavo-ensures-compliance-dora-mica) - [Retail: 99% Faster Kafka Onboarding](https://www.conduktor.io/customer-stories/one-hour-kafka-onboarding-retail-streaming-operations) - [European Airline: 25 Clusters to Cloud](https://www.conduktor.io/customer-stories/leading-european-airline-migrates-kafka-to-confluent-cloud-with-conduktor)