Schema Registry Proxy
Autorisieren. Auditieren. Kontrollieren.
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.
Schützen wir die Schema Registry so, wie wir Kafka schützen.
Wir haben den Schema Registry Proxy entwickelt, damit jede Schema-Operation autorisiert und protokolliert wird – auf der Registry, die Sie bereits betreiben, mit den Identitäten, die Sie bereits verwalten. Einfach einhängen und auf einen beliebigen Provider verweisen.
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.
Autorisierung sofort einsatzbereit
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.
Jede Operation lückenlos protokollieren
Standardmäßig gibt es kein Auditing für die Schema Registry. Bei Anbietern ist es ein weiterer kostenpflichtiger Tarif. Ein Schema ändert sich, Consumer brechen zusammen, und es gibt keinen Nachweis, wer es wann und warum getan hat. Compliance fordert Belege – und es gibt keine.
Jede Operation wird lückenlos nachverfolgt, jede Ablehnung wird mit dem Versuch und der Identität protokolliert, und jede Berechtigungsänderung wird aufgezeichnet.
Erteilen · Durchsetzen · Beobachten.
Weisen Sie jeder Anwendung ihre Subjects zu, lassen Sie den Proxy jeden Aufruf prüfen und protokollieren Sie alles. Berechtigungen kommen aus Console oder den Kafka ACLs, die Sie bereits verwalten.
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"
}Dieselbe Registry – abgesichert.
Hängen Sie den Proxy vor die Schema Registry, die Sie bereits betreiben.
An Ihren Anwendungen ändert sich nichts. Alles daran, wer Schemas anfassen darf, schon.
Vor dem Schema Registry Proxy
Manche Teams betreiben die Registry völlig offen. Die meisten stellen einen generischen HTTP-Proxy davor, der Routen und Token prüft. Beide bewachen die Tür, nicht die Schemas dahinter.
Nach dem Schema Registry Proxy
Jede Anfrage wird gegen Ihren Identity-Provider authentifiziert und anhand von Subject-spezifischen Berechtigungen geprüft. Fügen Sie Conduktor Console für föderiertes Ownership und menschliche Schema-Verwaltung hinzu.
Built to drop into your stack. Works with any registry that implements the Confluent Schema Registry API, including Confluent Cloud, Apicurio, and Karapace.
Subject-spezifische Berechtigungen
Read and write per subject, with exact, prefix, and wildcard matching. Checked on every request, before anything reaches your registry.
Ihr Identity-Provider
Keycloak, Auth0, Okta, Microsoft Entra ID oder ein beliebiger OAuth2/OIDC-Provider mit JWKS-Endpunkt. Automatische Key-Rotation inklusive.
Kafka-native Berechtigungen
Über ein Kafka-Topic aus Console geliefert und in Sekunden angewendet, oder aus Ihren bestehenden ACLs gelesen. Keine Neustarts, kein neuer Datenspeicher.
Versagen auf der sicheren Seite
Wenn eine Berechtigung nicht verifiziert werden kann, wird die Anfrage abgelehnt. Fehler und Timeouts führen nie zu offenem Zugriff.
Traces, Logs und Metriken
Ein OpenTelemetry-Trace pro Operation, jede Ablehnung mit der Identität des Aufrufers protokolliert, und Prometheus-Metriken sofort einsatzbereit.
Läuft dort, wo Kafka läuft
Ein einzelner Container, on-premises, in der Cloud oder air-gapped. Neben Gateway oder eigenständig.
Ressourcenrichtlinien · demnächst
Schema-Standards einmalig festlegen: Kompatibilitäts-Untergrenzen, Formatanforderungen und Namenskonventionen, bei der Registrierung für jedes Team und Tool durchgesetzt.
Rate Limiting · demnächst
Anfragelimits pro Principal, damit ein fehlerhafter Deploy in einer Neustart-Schleife die Registry nicht überschwemmt, auf die alle anderen Teams angewiesen sind.
Vier Wege, eine Schema Registry zu betreiben
Die meisten Teams befinden sich heute in einer der ersten drei Spalten.
| Kein Schutz | Generischer HTTP-Proxy | Confluent Platform RBAC | Schema Registry Proxy | |
|---|---|---|---|---|
| Autorisierung | Keine | Routen-Allowlists | Subject-spezifisches RBAC | ✓ Pro Subject, Präfix und Wildcard |
| Versteht | Nichts | URLs und Methoden | Subjects | ✓ Subjects und Ihre Kafka-Identitäten |
| Identität | Keine | Separate Auth-Konfiguration | Confluents Identitätsebene | ✓ OIDC / OAuth2, the same accounts as your Kafka |
| Funktioniert mit | Jede Registry | Jede Registry | Nur Confluent Platform | ✓ Any registry with the Confluent SR API |
| Lizenzierung | Kostenlos | Engineering-Aufwand | Vollständige Plattformlizenz | ✓ Standalone |
| Wartung | Keine | Ihr Team | Confluent | ✓ Conduktor |
Der Topic ACL Authorizer ist veraltet. Ihre ACLs müssen es nicht sein.
Jahrelang ermöglichte der Topic ACL Authorizer Topic-Besitzern, ihre eigenen Subjects zu verwalten. Confluent Platform 8.0 stuft ihn als veraltet ein, wodurch jedes Team, das darauf angewiesen ist, unter Migrationsdruck in Richtung Confluent RBAC gerät – einem Enterprise-Lizenz-Feature.
Es gibt eine dritte Option. Der Standalone-Modus des Proxys ist dem Authorizer nachempfunden: Dieselben Topic-ACLs steuern weiterhin dieselben Subjects. Zeigen Sie schema.registry.url auf den Proxy und aktualisieren Sie nach Ihrem eigenen Zeitplan. Keine RBAC-Migration, keine Plattformlizenz.
Muss ich meinen Anwendungscode ändern?
Nein. Aktualisieren Sie schema.registry.url in Ihrer Kafka-Client-Konfiguration, damit sie auf den Proxy zeigt. Producer und Consumer verwenden weiterhin ihre vorhandenen Serializer und Deserializer. Keine Code-Änderungen, kein Bibliothekswechsel.
Wie werden Berechtigungen verwaltet?
Auf zwei Wegen. Über Conduktor Console, wo Subjects Ihrem föderiertem Ownership-Modell beitreten und Änderungen über Kafka in Sekunden übernommen werden. Oder standalone, wo der Proxy die Kafka-Topic-ACLs liest, die Sie bereits verwalten. Console ist nicht erforderlich.
Kann er den Confluent Topic ACL Authorizer ersetzen?
Ja. Der Standalone-Modus ist ihm nachempfunden: Dieselben Topic-ACLs steuern dieselben Subjects mit derselben Semantik. Er funktioniert auf Confluent Platform 8.0 und darüber hinaus, wo der Authorizer veraltet ist. Das Deployment-Handbuch beschreibt die genaue Zuordnung.
Welche Schema Registries unterstützt der Proxy?
Confluent Schema Registry und jede Registry, die dieselbe REST API implementiert, einschließlich Confluent Cloud.
Was ist mit Löschungen und Kompatibilitätsänderungen?
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.
Wie verhält sich der Schema Registry Proxy zu Conduktor Gateway?
Dieselbe Philosophie auf einer anderen Ebene. Gateway sitzt vor Ihren Kafka-Clustern. Der Schema Registry Proxy sitzt vor Ihrer Registry. Beide setzen durch, wer was tun darf, ohne Clients zu berühren, und teilen dieselben Identitäten. Gemeinsam oder unabhängig voneinander bereitstellen.
Bereit, Ihre Schema Registry zu kontrollieren?
Unser Team führt Sie durch eine Bereitstellung, die zu Ihrem Identity-Provider, Ihrem Kafka-Setup und Ihren Compliance-Anforderungen passt.