Schema Registry Security Overview

Schema Registry currently supports all Kafka security features, including:

For more details, check the configuration options.


For a configuration example that uses Schema Registry configured with security, see 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 slave to master node calls for writes and deletes will use the specified protocol. The default value would be http. When https is set, ssl.keystore. and ssl.truststore. configs are used while making the call. The schema.registry.inter.instance.protocol name is deprecated; prefer using inter.instance.protocol instead.

  • 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 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

Configuring the REST API for Basic HTTP Authentication

Schema Registry can be configured to require users to authenticate using a username and password via the Basic HTTP authentication mechanism.


If you're using Basic authentication, we recommended that you configure Schema Registry to use HTTPS for secure communication, because the Basic protocol passes credentials in plain text.

Use the following settings to configure Schema Registry to require authentication:


The authentication.roles config defines a comma-separated list of user roles. To be authorized to access Schema Registry, an authenticated user must belong to at least one of these roles.

For example, if you define admin, developer, user, and sr-user roles, the following configuration assigns them for authentication:


The authentication.realm config must match a section within jaas_config.file, which defines how the server authenticates users and should be passed as a JVM option during server start:

<path-to-confluent>/bin/schema-registry-start <path-to-confluent>/etc/schema-registry/

An example jaas_config.file is:

SchemaRegistry-Props {
  org.eclipse.jetty.jaas.spi.PropertyFileLoginModule required

Assign the SchemaRegistry-Props section to the authentication.realm config setting:


The example jaas_config.file above uses the Jetty PropertyFileLoginModule, which authenticates users by checking for their credentials in a password file.

You can also use other implementations of the standard Java LoginModule interface, such as the LdapLoginModule, or the JDBCLoginModule for reading credentials from a database.

The file parameter is the location of the password file, The format is:

<username>: <password-hash>[,<rolename> ...]

Here’s an example:

fred: OBF:1w8t1tvf1w261w8v1w1c1tvn1w8x,user,admin
harry: changeme,user,developer
tom: MD5:164c88b302622e17050af52c89945d44,user
dick: CRYPT:adpexzg3FUZAk,admin,sr-user

Get the password hash for a user by using the utility:

bin/schema-registry-run-class fred letmein

Your output should resemble:


Each line of the output is the password encrypted using different mechanisms, starting with plain text.

Once Schema Registry is configured to use Basic authentication, clients must be configured with suitable valid credentials, for example:


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.