Deploy Schema Registry Proxy

The Schema Registry Proxy (SRP) sits between your Kafka client applications and Confluent Schema Registry, adding authentication, per-subject authorization and observability. It exposes the same REST API that the Confluent serializers and deserializers use, so applications only change their Schema Registry URL (and credentials) to go through the proxy.

Only Confluent-compatible schema registries are supported.

SRP is explicitly and only a proxy for application clients — producers, consumers and their serializers/deserializers, plus read-only tooling — connecting to Schema Registry. It does not implement the entire Confluent Schema Registry API and does not support administrative operations: subject and schema deletion, compatibility and mode writes (PUT/DELETE on /config and /mode) and schema-linking /exporters endpoints are not routed and return 404. For administrative work, use Conduktor Console, which connects to the Schema Registry directly to manage subjects, schemas and compatibility settings.

From our blog: Introducing Schema Registry Proxy How SRP adds authentication, authorization, and observability on top of Confluent Schema Registry.

Want Schema Registry Proxy?

Talk to our team to get deployment help and a working setup on your stack.

Prerequisites

Requirement	Details
Conduktor license	A Conduktor Scale or Gateway license, passed in `CDK_LICENSE`. SRP refuses to start without a valid one.
Confluent Schema Registry	Version 7.0+. The backend SRP proxies requests to.
Authentication provider	An OIDC-compliant provider with a JWKS endpoint (for example, Keycloak, Auth0, Okta) for JWT authentication, or a mounted credentials file for HTTP Basic authentication.
Apache Kafka	Version 3.8+. Required by the `reactive` mode (permission distribution and heartbeat discovery) and the `topic-acl` mode (ACL lookups). Not required by `read-only` mode.
Conduktor Console	Required by the `reactive` authorization mode only, for Self-service permission management.

How requests flow

Every client request is authenticated, authorized against the schema subject, then forwarded to the backend registry. Only two permissions exist: Write is required to register a schema (POST /subjects/{subject}/versions); every other proxied endpoint requires Read. A denied request returns 403. SRP authenticates to the backend registry with its own credentials — client credentials are never forwarded upstream.

Authorization modes

AUTHORIZATION_MODE selects one of three modes. Exactly one is active per deployment, and only reactive requires Conduktor Console or Conduktor-specific Kafka topics.

Reactive (default)

Permissions are managed in Conduktor Console via Self-service — you apply Application Instances and Application Instance Permissions with the Conduktor CLI — and Console distributes them to SRP over Kafka: Console discovers SRP instances through heartbeats on the _conduktor_srp_events topic and publishes permission updates to the _conduktor_srp_commands topic, which SRP consumes and stores in memory. Use it when you run Conduktor Console and want schema permissions managed centrally alongside your other Self-service resources, updated in real time without restarting the proxy, and kept consistent across multiple SRP instances.

Grant schema permissions with an ApplicationInstance

Permissions are expressed as SUBJECT resources on an ApplicationInstance: every subject matching the resource is authorized for the instance’s serviceAccount. In this example, the orders-producer service account gets access to every subject whose name starts with orders — so under TopicNameStrategy it can register and fetch orders-value, orders-key and any other orders* subject through the proxy:

---
apiVersion: self-serve/v1
kind: Application
metadata:
  name: "orders-app"
spec:
  title: "Orders"
  description: "Order processing application"
  owner: "orders-team"
---
apiVersion: self-serve/v1
kind: ApplicationInstance
metadata:
  application: "orders-app"
  name: "orders-app-prod"
spec:
  cluster: "prod-kafka"
  serviceAccount: "orders-producer"
  resources:
    - type: TOPIC
      patternType: PREFIXED
      name: "orders"
    - type: SUBJECT
      patternType: PREFIXED
      name: "orders"

conduktor apply -f orders-app.yaml

Console publishes the permissions to the command topic, SRP consumes them, and the grant takes effect without a restart. The serviceAccount name has to match the identity SRP authenticates — with JWT authentication, the claim selected by JWT_SUBJECT_CLAIM_NAME. A caller whose service account has no matching SUBJECT resource gets 403 on every schema operation, which is also the starting state for every new service account.

Topic ACL (standalone)

SRP authorizes schema operations against the Kafka topic Access Control Lists (ACLs) already defined in your cluster, fetched through the Kafka Admin API. The subject maps to its topic following Confluent’s TopicNameStrategy (orders-value → topic orders); Read requires a READ ACL and Write requires WRITE (ALL matches either — note Write does not imply Read in this mode, so a producer principal that also fetches schemas needs READ or ALL). The authenticated identity is checked as User:{name}, wildcard User:* bindings match, both LITERAL and PREFIXED patterns apply, a matching DENY always wins, and every failure (broker error, timeout, no matching ACL) denies the request. ACL lookups are cached per topic (default TTL 500ms). Use it when your Kafka ACLs are already the source of truth for access control: a principal that can read or write a topic automatically gets the matching access to its schemas, with no second permission system to operate — no Console, no Conduktor-specific topics. How a single check runs, including the cache and the fail-closed paths:

Read-only (standalone)

Every authenticated read passes through to the backend; every write is rejected with 403. This mode needs no Kafka connection at all. Paired with AUTH_PROVIDER=basic (credentials read from a mounted file), the whole deployment is just the proxy, the credentials file and the backend registry — no OAuth provider, no Console, no Kafka. Use it when you want the simplest possible deployment: authenticated read access to schemas for consumers, dashboards and CI tooling, with a guarantee that nothing can be modified through the proxy.

Super users (all modes)

AUTHORIZATION_SUPER_USERS accepts a semicolon-separated list of service account names that bypass all authorization checks — including explicit DENY ACLs in topic-acl mode and the write block in read-only mode. Leave it empty (the default) unless you need a break-glass identity.

Enable SRP discovery in Console (reactive mode)

Set the following environment variable on your Console deployment:

environment:
  CDK_SCHEMAREGISTRYPROXY_ENABLED: "true"

Once SRP is running, the proxy instance appears in Console:

Go to the Kafka cluster configured as the SRP backing cluster.
Open the Schema Registry tab for a Schema Registry with ConfluentLike flavor.
Select the discovered SRP instance from the dropdown.

Deploy with Docker Compose

services:
  schema-registry-proxy:
    image: conduktor/conduktor-schema-registry-proxy:1.0.0
    hostname: schema-registry-proxy
    depends_on:
      kafka:
        condition: service_healthy
      schema-registry:
        condition: service_healthy
    environment:
      PORT: "7070"
      CDK_LICENSE: ${CDK_LICENSE}
      KAFKA_BOOTSTRAP_SERVERS: <YOUR_KAFKA_BOOTSTRAP>
      CONFLUENT_SCHEMA_REGISTRY_URL: <YOUR_SCHEMA_REGISTRY_URL>
      AUTH_PROVIDER: jwt
      JWT_JWKS_URL: <YOUR_JWKS_ENDPOINT>
      SCHEMA_REGISTRY_PROXY_APP_ID: srp-cluster-1
      OTEL_EXPORTER_OTLP_ENDPOINT: <YOUR_OTLP_COLLECTOR_ENDPOINT>
    ports:
      - "7070:7070"
      - "9464:9464"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:7070/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s

AUTH_PROVIDER is required and has no default: set it to jwt or basic or the proxy refuses to start. The example uses the default reactive authorization mode; see standalone deployment examples for topic-acl and read-only setups.

Verify deployment

Check that SRP is healthy:

curl http://host:${PORT}/health

Confirm Prometheus metrics are available. /metrics is served on the Prometheus port (OTEL_PROMETHEUS_PORT, default 9464), and only when OTEL_EXPORTER_OTLP_ENDPOINT is set:

curl http://host:${OTEL_PROMETHEUS_PORT}/metrics

In reactive mode, verify the SRP instance appears in the Console Schema Registry tab dropdown for the relevant cluster.

Conduktor in production

Deploy Console