Schema Registry Proxy
Autorisieren. Auditieren. Kontrollieren.
Ein Proxy mit Schema-Registry-Verständnis, der Zugriffskontrolle, Auditing und Policy-Durchsetzung zu der Schema Registry hinzufügt, die Sie bereits betreiben. Richten Sie Ihre Clients darauf aus. Keine Codeänderungen.
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.
Spricht Schema, nicht nur HTTP
Die übliche Lösung ist nginx oder ein API-Gateway vor der Registry. Vernünftig, aber das schützt Routen und Methoden, nicht Subjects. Es kann eine neue Version nicht von einem destruktiven Überschreiben unterscheiden, weil es nicht weiß, was ein Subject oder ein Schema ist.
Der Proxy spricht die API der Schema Registry selbst. Er denkt in Subjects, Versionen und Kompatibilität, sodass jede Regel in den Begriffen der Registry formuliert ist.
Autorisierung sofort einsatzbereit
Open-Source-Registries bieten grobe Rollen oder eine Passwortdatei, aber keine Kontrolle pro Subject. Confluents Antwort ist RBAC in Confluent Platform, oft über 100.000 $ pro Jahr. So oder so kann jeder mit Zugriff jedes Schema ändern, und die Last liegt bei Ihnen.
Lese- und Schreibrechte pro Subject, bei jeder Anfrage geprüft, auf der Registry, die Sie bereits betreiben. Und sie kommen von dort, wo sie ohnehin leben: aus Ihren Kafka-ACLs oder aus dem föderierten Ownership in Console. Keine Plattformlizenz.
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.
Ein Schema ist ein bewusstes Artefakt, kein Unfall zur Laufzeit
Die meisten Schema-Vorfälle beginnen gleich: Das Schema entsteht als Nebeneffekt der ersten Nachricht, die ein Service sendet. Liefern Sie es stattdessen bewusst aus, und die Fehler verlagern sich nach vorn in den Code-Review, wo sie günstig zu beheben sind.
Bewusst registrieren
Der Confluent-Serializer registriert ein Schema beim ersten Produce: auto.register.schemas ist standardmäßig aktiv. Die Registrierung passiert, sobald dieser Codepfad zum ersten Mal läuft, oft Stunden nach dem Deploy, sodass ein Bruch schwer auf seine Ursache zurückzuführen ist. Provisionieren Sie Schemas vor dem Deploy, dann validiert die Registry sie, bevor irgendetwas ausgeliefert wird.
Eine Kompatibilitätshistorie pro Umgebung
Dev sammelt mehr Versionen als QA, QA mehr als Prod. Jede Umgebung hat ihre eigene Kompatibilitätslinie, also kann eine Änderung, die in Dev durchgeht, gegenüber Prod trotzdem abgelehnt werden. Prüfen Sie sie gegen die Umgebung, in die Sie promoten, und Dev warnt Sie, bevor Sie dort ankommen.
Schemas als Code
Halten Sie Subjects in der Versionskontrolle, prüfen Sie sie im Pull Request, wenden Sie sie aus der CI an. Das Manifest, das der Proxy liest, ist eine Datei in Ihrem Repository: Ein Schema weiterzuentwickeln ist damit ein Diff, den jemand freigibt, und kein Aufruf, den eine Anwendung zur Laufzeit macht.
Für Ihren Stack gebaut. Funktioniert mit jeder Registry, die die Confluent-Schema-Registry-API implementiert, einschließlich Confluent Cloud, Apicurio und Karapace.
Subject-spezifische Berechtigungen
Lesen und Schreiben pro Subject, mit exakter, Präfix- und Wildcard-Zuordnung. Bei jeder Anfrage geprüft, bevor irgendetwas Ihre Registry erreicht.
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
Setzen Sie Schema-Standards einmal: Mindest-Kompatibilitätsstufen, Formatanforderungen, Namens- und Namespace-Konventionen sowie erforderliche Dokumentation. Alles wird bei der Registrierung durchgesetzt, für jedes Team und jedes Tool.
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, dieselben Konten wie Ihr Kafka |
| Funktioniert mit | Jede Registry | Jede Registry | Nur Confluent Platform | ✓ Jede Registry mit der 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.
Der Wechsel zu RBAC ist kein Konfigurations-Flag. Die topicbasierten Berechtigungen, die Ihre Teams aufgebaut haben, müssen als Role Bindings neu modelliert und über jeden Cluster und jede Umgebung hinweg neu geschrieben werden, zusätzlich zur Plattformlizenz ein eigenes Change-Programm.
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 können Anwendungen über den Proxy tun?
Nur das, was sie brauchen: produzieren und konsumieren anhand bereits vorhandener Schemas. Die Evolution, also neue Versionen, Kompatibilitätsänderungen und Löschungen, läuft über einen kontrollierten Workflow wie Console, sodass destruktive und Konfigurations-Endpunkte nie auf dem Pfad liegen, den eine Anwendung nutzt. Und wenn die Registrierung zur Laufzeit deaktiviert ist, kann ein Client kein Schema mehr registrieren, wenn er zum ersten Mal produziert, Stunden nach dem Deploy, genau dort, wo Auto-Registrierung normalerweise zubeißt.
Warum sollten Löschungen und Kompatibilitätsänderungen von Anwendungen ferngehalten werden?
Weil beides nahezu irreversibel ist. Löschen Sie ein Subject oder eine Version, wird jede Nachricht, die noch dagegen serialisiert wurde, unlesbar: Sie verlieren die Fähigkeit, Ihre eigene Historie zu deserialisieren, so wie ein verlorener Schlüssel verschlüsselte Daten unwiederbringlich macht. Den Kompatibilitätsmodus eines Subjects zu lockern ist leiser, aber genauso schädlich: Die nächste inkompatible Version geht ohne Fehler durch, und die Garantie, auf die sich jeder Consumer verlassen hat, ist weg. Das sind bewusste, autorisierte Handlungen und nichts, was eine Anwendung oder eine versehentlich offene UI auslösen können sollte.
Warum nicht einfach die eigene Autorisierung der Schema Registry nutzen?
Es gibt zwei native Optionen, und beide enttäuschen. Die eine leitet Berechtigungen aus Kafka ab: Wer ein Topic schreiben darf, darf auch dessen Subject schreiben, das bot der Topic ACL Authorizer, der in Confluent Platform 8.0 inzwischen veraltet ist. Die andere ist eine native Permissions-API, um die herum jedoch kaum Ökosystem-Tooling entstanden ist: kein Terraform, kein Ansible, keine Wrapper, also haben sie nur wenige Teams übernommen. Bleibt Confluent RBAC und die volle Plattformlizenz. Der Proxy gibt Ihnen Autorisierung pro Subject auf jeder Registry, mit den Kafka-Identitäten, die Sie bereits haben, ohne diesen Kompromiss.
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.