Schema Registry Proxy
Autoriser. Auditer. Gouverner.
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.
Protégeons le schema registry comme nous protégeons Kafka.
Nous avons conçu le Schema Registry Proxy pour que chaque opération sur les schémas soit autorisée et tracée, sur le registry que vous exploitez déjà, avec les identités que vous gérez déjà. Déployez-le et pointez-le vers n'importe quel fournisseur.
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.
Autorisation prête à l'emploi
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.
Tracez chaque opération
Par défaut, l'audit du schema registry n'existe pas. Chez les éditeurs, c'est un niveau payant supplémentaire. Un schéma change, les consumers tombent, et il n'existe aucune trace de qui l'a fait, quand, ni pourquoi. La conformité réclame des preuves et vous n'en avez aucune à fournir.
Chaque opération est tracée de bout en bout, chaque refus est journalisé avec l'identité de l'auteur, et chaque modification de permission est enregistrée.
Accorder · Appliquer · Observer.
Attribuez à chaque application ses subjects, laissez le proxy vérifier chaque appel et conservez une trace de tout. Les permissions proviennent de Console ou des ACLs Kafka que vous gérez déjà.
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"
}Le même registry, sécurisé.
Placez le proxy devant le schema registry que vous exploitez déjà.
Rien ne change pour vos applications. Tout change quant à qui peut modifier les schémas.
Avant Schema Registry Proxy
Certaines équipes laissent le registry totalement ouvert. La plupart le font précéder d'un proxy HTTP générique qui vérifie les routes et les tokens. Dans les deux cas, on protège la porte, pas les schémas derrière.
Après Schema Registry Proxy
Chaque requête est authentifiée auprès de votre fournisseur d'identité et vérifiée par rapport aux permissions par subject. Ajoutez Conduktor Console pour la propriété fédérée et la gestion humaine des schémas.
Built to drop into your stack. Works with any registry that implements the Confluent Schema Registry API, including Confluent Cloud, Apicurio, and Karapace.
Permissions par subject
Read and write per subject, with exact, prefix, and wildcard matching. Checked on every request, before anything reaches your registry.
Votre fournisseur d'identité
Keycloak, Auth0, Okta, Microsoft Entra ID, ou tout fournisseur OAuth2/OIDC disposant d'un endpoint JWKS. Rotation automatique des clés incluse.
Permissions natives Kafka
Distribuées via un topic Kafka depuis Console et appliquées en quelques secondes, ou lues depuis vos ACLs existantes. Sans redémarrage, sans nouveau datastore.
Échec sécurisé
Si une permission ne peut être vérifiée, la requête est refusée. Les erreurs et les timeouts ne conduisent jamais à un accès autorisé par défaut.
Traces, logs et métriques
Une trace OpenTelemetry par opération, chaque refus journalisé avec l'identité de l'appelant, et des métriques Prometheus prêtes à l'emploi.
S'exécute là où Kafka s'exécute
Un seul conteneur, on-premises, dans le cloud ou en environnement isolé. Aux côtés de Gateway ou de manière autonome.
Politiques de ressources · à venir
Définissez les standards de schémas une seule fois : niveaux de compatibilité minimaux, exigences de format et conventions de nommage, appliqués à l'enregistrement pour chaque équipe et chaque outil.
Limitation de débit · à venir
Limites de requêtes par principal, pour qu'un déploiement défaillant en boucle de redémarrage ne puisse pas saturer le registry dont dépendent toutes les autres équipes.
Quatre façons d'opérer un Schema Registry
La plupart des équipes se trouvent aujourd'hui dans l'une des trois premières colonnes.
| Aucune protection | Proxy HTTP générique | Confluent Platform RBAC | Schema Registry Proxy | |
|---|---|---|---|---|
| Autorisation | Aucune | Listes d'autorisation de routes | RBAC par subject | ✓ Par subject, préfixe et joker |
| Comprend | Rien | URLs et méthodes | Subjects | ✓ Les subjects et vos identités Kafka |
| Identité | Aucune | Configuration d'auth séparée | Plan d'identité Confluent | ✓ OIDC / OAuth2, the same accounts as your Kafka |
| Compatible avec | Tout registry | Tout registry | Confluent Platform uniquement | ✓ Any registry with the Confluent SR API |
| Licence | Gratuit | Temps d'ingénierie | Licence de plateforme complète | ✓ Autonome |
| Maintenance | Aucune | Votre équipe | Confluent | ✓ Conduktor |
Le Topic ACL Authorizer est déprécié. Pas vos ACLs.
Pendant des années, le Topic ACL Authorizer a permis aux propriétaires de topics de gouverner leurs propres subjects. Confluent Platform 8.0 le déprécie, ce qui place chaque équipe qui en dépend sur un calendrier de migration vers Confluent RBAC, une fonctionnalité sous licence enterprise.
Il existe une troisième option. Le mode autonome du proxy s'inspire de l'authorizer : les mêmes ACLs de topics continuent de gouverner les mêmes subjects. Pointez schema.registry.url vers le proxy et migrez selon votre propre calendrier. Sans migration RBAC, sans licence de plateforme.
Dois-je modifier le code de mon application ?
Non. Mettez à jour schema.registry.url dans la configuration de votre client Kafka pour pointer vers le proxy. Les producers et consumers continuent d'utiliser leurs serializers et deserializers existants. Aucune modification de code, aucun changement de bibliothèque.
Comment les permissions sont-elles gérées ?
De deux façons. Via Conduktor Console, où les subjects rejoignent votre modèle de propriété fédérée et les modifications s'appliquent en quelques secondes via Kafka. Ou en mode autonome, où le proxy lit les ACLs de topics Kafka que vous gérez déjà. Console n'est pas obligatoire.
Peut-il remplacer le Confluent Topic ACL Authorizer ?
Oui. Le mode autonome s'en inspire : les mêmes ACLs de topics gouvernent les mêmes subjects, avec la même sémantique. Il fonctionne sur Confluent Platform 8.0 et au-delà, où l'authorizer est déprécié. Le guide de déploiement couvre le mapping exact.
Quels schema registries le proxy prend-il en charge ?
Confluent Schema Registry et tout registry implémentant la même API REST, y compris Confluent Cloud.
Qu'en est-il des suppressions et des changements de compatibilité ?
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.
Quel est le lien entre le Schema Registry Proxy et Conduktor Gateway ?
La même philosophie à une couche différente. Gateway se place devant vos clusters Kafka. Le Schema Registry Proxy se place devant votre registry. Les deux appliquent les droits d'accès sans toucher aux clients, et ils partagent les mêmes identités. Déployez-les ensemble ou séparément.
Prêt à gouverner votre schema registry ?
Notre équipe peut vous accompagner dans un déploiement adapté à votre fournisseur d'identité, votre configuration Kafka et vos exigences de conformité.