You are viewing documentation for an older version of Confluent Platform. For the latest, click here.

Schema Registry Security Overview

Schema Registry currently supports all Kafka security features, including:

For more details, check the configuration options.

If you want to see full configurations for a secured Schema Registry, please refer to the Confluent Platform demo

Kafka Store

Schema Registry uses Kafka to persist schemas, and all Kafka security features are supported by Schema Registry.


Schema Registry supports both unauthenticated and SASL authentication to ZooKeeper.

Setting up ZooKeeper SASL authentication for Schema Registry is similar to Kafka’s setup. Namely, create a keytab for Schema Registry, create a JAAS configuration file, and set the appropriate JAAS Java properties.

In addition to the keytab and JAAS setup, be aware of the zookeeper.set.acl setting. This setting, when set to true, enables ZooKeeper ACLs, which limits access to znodes.

Important: if zookeeper.set.acl is set to true, Schema Registry’s service name must be the same as Kafka’s, which is kafka by default. Otherwise, Schema Registry will fail to create the _schemas topic, which will cause a leader not available error in the DEBUG log. Schema Registry log will show org.apache.kafka.common.errors.TimeoutException: Timeout expired while fetching topic metadata when Kafka does not set ZooKeeper ACLs but Schema Registry does. Schema Registry’s service name can be set either with or in the JAAS file.

If Schema Registry has a different service name than Kafka, at this time zookeeper.set.acl must be set to false in both Schema Registry and Kafka.

Configuring the REST API for HTTP or HTTPS

By default Schema Registry allows you to make REST API calls over HTTP. You may configure Schema Registry to allow either HTTP or HTTPS or both at the same time.

The following configuration determines the protocol used by Schema Registry:


Comma-separated list of listeners that listen for API requests over HTTP or HTTPS or both. If a listener uses HTTPS, the appropriate SSL configuration parameters need to be set as well.

On the clients, configure schema.registry.url to match the configured Schema Registry listener.

Additional configurations for HTTPS

If you configure an HTTPS listener, there are several additional configurations for Schema Registry.

First, configure the appropriate SSL configurations for the keystore and optionally truststore. The truststore is required only when ssl.client.auth is set to true.


You may specify which protocol to use while making calls between the instances of Schema Registry. The slave to master node calls for writes and deletes will use the specified protocol.


The protocol used while making calls between the instances of Schema Registry. The default value is http. When https is set, ssl.keystore. and ssl.truststore. configs are used while making the call.

  • Type: string
  • Default: “http”
  • Importance: low

To configure clients to use HTTPS to Schema Registry:

  1. On the client, configure the schema.registry.url to match the configured listener for HTTPS.
  2. On the client, configure the environment variables to set the SSL keystore and truststore. You will need to set the appropriate env variable depending on the client (one of KAFKA_OPTS, SCHEMA_REGISTRY_OPTS, KSQL_OPTS). For example:
export KAFKA_OPTS=" \

Migrating from HTTP to HTTPS

To upgrade Schema Registry to allow REST API calls over HTTPS in an existing cluster:

  • Add/Modify the listeners config to include HTTPS. For example:,
  • Configure Schema Registry with appropriate SSL configurations to setup the keystore and optionally truststore
  • Do a rolling bounce of the cluster

This process enables HTTPS, but still defaults to HTTP so Schema Registry instances can still communicate before all nodes have been restarted. They will continue to use HTTP as the default until configured not to. To switch to HTTPS as the default and disable HTTP support, perform the following steps:

  • Enable HTTPS as mentioned in first section of upgrade (both HTTP & HTTPS will be enabled)
  • Configure schema.registry.inter.instance.protocol to https in all the nodes
  • Do a rolling bounce of the cluster
  • Remove http listener from the listeners in all the nodes
  • Do a rolling bounce of the cluster

Authorizing Access to the Schemas Topic

Relatively few services need access to Schema Registry, and they are likely internal, so you can restrict access via firewall rules and/or network segmentation.

Note that if you have enabled Kafka authorization, you will need to grant read and write access to this topic to Schema Registry’s principal.

export KAFKA_OPTS="<path to JAAS conf file>"

bin/kafka-acls --authorizer-properties zookeeper.connect=localhost:2181 --add --allow-principal 'User:<sr-principal>' --allow-host '*' --operation Read --topic _schemas

bin/kafka-acls --authorizer-properties zookeeper.connect=localhost:2181 --add --allow-principal 'User:<sr-principal>' --allow-host '*' --operation Write --topic _schemas


Removing world-level permissions: In previous versions of Schema Registry, we recommended making the _schemas topic world readable and writable. Now that Schema Registry supports SASL, the world-level permissions can be dropped.