Schema Registry Proxy
Autorisieren. Auditieren. Kontrollieren.
Ein Kafka-bewusster Proxy, der Zugriffskontrolle, Auditing und Richtliniendurchsetzung zur bestehenden Schema Registry hinzufügt. Ohne Client-Ä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 jeden Provider zeigen.
Autorisierung sofort einsatzbereit
Die kostenlose Schema Registry von Confluent bietet keine Autorisierung: Jeder mit Zugriff kann jedes Schema ändern. Die Lösung? Confluent Platform, oft über 100.000 $ pro Jahr. Open-Source-Optionen: grobe Rollen oder Passwortdateien. In jedem Fall liegt die Last bei Ihnen.
Pro-Subject Lese- und Schreibberechtigungen, bei jeder Anfrage geprüft, auf der Registry, die Sie bereits betreiben. 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.
Kafka-Berechtigungen übernehmen
Die übliche Lösung ist nginx oder ein API-Gateway vor der Registry. Sinnvoll, aber es schützt Routen, nicht Subjects. Es kann keine Berechtigungen übernehmen, die Sie bereits in Kafka oder Console verwalten, und die Anbindung Ihres Identity-Providers ist Konfiguration, die dauerhaft gepflegt werden muss.
Berechtigungen kommen aus ihrer Quelle: Ihre Kafka ACLs oder föderiertes Ownership in Console. OIDC und Key-Rotation inklusive.
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.
Entwickelt, um nahtlos in Ihren Stack integriert zu werden. Funktioniert mit jeder Confluent-API-kompatiblen Schema Registry, einschließlich Confluent Cloud.
Subject-spezifische Berechtigungen
Lese- und Schreibzugriff pro Subject, mit exaktem, Präfix- und Wildcard-Abgleich. Bei jeder Anfrage geprüft, bevor etwas 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
Schema-Standards einmalig festlegen: Kompatibilitätsgrenzen, 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 | ✓ Dieselben Konten wie Ihr Kafka |
| Funktioniert mit | Jeder Registry | Jeder Registry | Nur Confluent Platform | ✓ Jeder Confluent-API-Registry |
| 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 veraltet ihn, wodurch jedes Team, das darauf angewiesen ist, auf eine Migrationsuhr in Richtung Confluent RBAC gesetzt wird – einem Enterprise-Lizenz-Feature.
Es gibt eine dritte Option. Der Standalone-Modus des Proxy 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 denselben Semantiken. 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?
Sie können die Registry nicht über den Proxy erreichen. Anwendungen erhalten nur die Endpunkte, die sie zum Produzieren und Konsumieren benötigen – nichts Destruktives. Die Schema-Verwaltung erfolgt über Console, wo sie kontrolliert und protokolliert wird.
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.