Schema Registry ACL Authorizer for Confluent Platform

Schema Registry ACL Authorizer is a fine-grained authorizer which relies on ACLs defined for specific Schema Registry Operations against the subjects. It can be used independently or in conjunction with Role-Based Access Control (RBAC), as described below.

Tip

  • Schema Registry ACL Authorizer does not support schema exporters. To implement access control on exporters, use RBAC as described in Access Control (RBAC) for Schema Linking Exporters.
  • SCHEMA_READ is the only operation that cannot be defined and managed explicitly through ACLs with the Schema Registry ACL Authorizer. It relies on SUBJECT_READ grant on at least one of the subjects that the schema ID is associated with.

Prerequisites

Enable ACL Authorizer

Set the java.security.auth.login.config system property.

export SECURITY_PLUGINS_OPTS=-Djava.security.auth.login.config=/etc/schema-registry/kafka_client_jaas.conf

Note

If you’ve already configured kafkastore.sasl.jaas.config in your Schema Registry properties file (/etc/schema-registry/schema-registry.properties) to run the Schema Registry ACL CLI tool, then SECURITY_PLUGINS_OPTS is not required. In this case, the Schema Registry properties file already includes all the information required to communicate with the Kafka broker, including security credentials.

Enable for ACLs only

Add the following config to the Schema Registry config file:

confluent.schema.registry.authorizer.class=io.confluent.kafka.schemaregistry.security.authorizer.schemaregistryacl.SchemaRegistryAclAuthorizer

You can manage the Schema Registry ACLs through the Schema Registry ACL CLI tool and the ACLs stored in a separate topic based on the configuration shown below.

The Schema Registry ACL CLI communicates directly to the Apache Kafka® brokers in the Schema Registry properties. For a secure broker with ACLs, you should use the CLI directly from the Schema Registry host and the same authenticated user as the Schema Registry service. This ensures that the tool has the appropriate ACLs and access to the broker.

Enable for ACLs and RBAC

If you want to use both ACLs and Role-Based Access Control (RBAC), then specify the RbacAndAclAuthorizer config in the Schema Registry config file as follows :

confluent.schema.registry.authorizer.class=io.confluent.kafka.schemaregistry.security.authorizer.RbacAndAclAuthorizer

confluent.schema.registry.acl.topic

The topic used to store ACLs for the Schema Registry operations. This is optional. If this configuration is used, the topic name is derived as kafkastore.topic and is suffixed with _acl.

  • Type: string
  • Default: “”
  • Importance: medium

Schema Registry ACL CLI

Schema Registry ACLs can be managed through Schema Registry ACL CLI tool. Run the Schema Registry ACL CLI tool to view the available options:

sr-acl-cli

Usage:
Option                      Description
------                      -----------
-h, --help                  Print usage information.
--add                       Indicates you are trying to add ACLs.
--remove                    Indicates you are trying to remove ACLs.
--list                      List all the current ACLs
--config <File>             REQUIRED: Schema Registry properties file
-o, --operation <String>    Operation that is being authorized. Valid operation
                              names are:
                            [SUBJECT_READ, SUBJECT_WRITE, SUBJECT_DELETE,
                              SUBJECT_COMPATIBILITY_READ,
                              SUBJECT_COMPATIBILITY_WRITE,
                              GLOBAL_COMPATIBILITY_READ,
                              GLOBAL_COMPATIBILITY_WRITE, GLOBAL_READ]
-s, --subject <String>      Subject to which the ACL is being applied to. Only
                              applicable for SUBJECT operations. Use * to apply
                              to all subjects
-t, --topic <String>        Topic to which the ACL is being applied to. The
                              corresponding subjects would topic-key and topic-
                              value.Only applicable for SUBJECT operations. Use
                              * to apply to all subjects
-p, --principal <String>    Principal to which the ACL is being applied to. Use
                              * to apply to all principals

Adding ACLs

Below are various examples of adding to Schema Registry ACLs.

Important

These examples assume you are running these commands from the home directory of your Confluent Platform installation.

  1. Add write access to subject test-subject-value for user Bob.

    ./bin/sr-acl-cli --config ./etc/schema-registry/schema-registry.properties --add -s test-subject-value -p Bob -o SUBJECT_WRITE

  2. Add write access for subjects test-subject-key and test-subject-value for user Bob.

    ./bin/sr-acl-cli --config ./etc/schema-registry/schema-registry.properties --add -t test-subject -p Bob -o SUBJECT_WRITE

  3. Add read and write access to subject test-subject-value for user Bob.

    ./bin/sr-acl-cli --config ./etc/schema-registry/schema-registry.properties --add -s test-subject-value -p Bob -o SUBJECT_WRITE:SUBJECT_READ

  4. Allow user Alice to manage global compatibility.

    ./bin/sr-acl-cli --config ./etc/schema-registry/schema-registry.properties --add -s test-subject-value -p Alice -o GLOBAL_COMPATIBILITY_READ:GLOBAL_COMPATIBILITY_WRITE

  5. Allow user Ted to read, write, and manage global compatibility for topics prefixed with dev-, using the wildcard (*).

    ./bin/sr-acl-cli --config ./etc/schema-registry/schema-registry.properties --add -t dev-'*' -p Ted -o GLOBAL_COMPATIBILITY_READ:GLOBAL_COMPATIBILITY_WRITE

  6. Create an admin user schema-admin.

    Important

    You must enclose the asterisk in quotes ('*').

    ./bin/sr-acl-cli --config ./etc/schema-registry/schema-registry.properties --add -s '*' -p schema-admin -o '*'

Adding Prefixed ACLs

Prefixed ACLs are supported, similar to the prefix pattern that RBAC rolebindings and Kafka ACLs support. (See, for instance, Using centralized ACLs.)

For example, the following would match all subjects in Schema Registry with names starting with svc and give the principal SUBJECT_WRITE permissions on those subjects.

sr-acl-cli --config <config> -add -s 'svc*' -p <principal> -o SUBJECT_WRITE

You can use topic prefixing to specify ACLs for topics. Following is an example of using a wildcard with prefixing to specify ACLs for all topics that start with dev-.

sr-acl-cli -add --config /etc/kafka/acl-schema-registry.properties -o SUBJECT_READ:SUBJECT_WRITE:SUBJECT_COMPATIBILITY_READ -t 'dev-*' -p user

Removing ACLs

Remove ACL command is similar to that of add ACL, except that you ue the option --remove instead of --add.

Remove write access to subject test-subject-value for user Bob

./bin/sr-acl-cli --config ./etc/schema-registry/schema-registry.properties --remove -s test-subject-value -p Bob -o SUBJECT_WRITE

Listing ACLs

This command lists all ACLs that have been defined.

./bin/sr-acl-cli --config ./etc/schema-registry/schema-registry.properties --list

Required ACLs

In addition to defining access privileges for principals to topics and subjects, you must specify the following ACLs on the internal schemas topic (default topic name is _schemas):

Topic: _schemas
User:registry has Allow permission for operations: Read from hosts: *
User:registry has Allow permission for operations: Write from hosts: *
User:registry has Allow permission for operations: Describe from hosts: *
User:registry has Allow permission for operations: DescribeConfigs from hosts: *
User:registry has Allow permission for operations: Create from hosts: *

Cluster
:User:registry has Allow permission for operations: Describe from hosts: *

If the above ACLs are not defined, Schema Registry will fail to start with an error message indicating that it is not authorized to access topics.

Tip

If you are using ACLs in combination with role-based access control (RBAC), the Schema Registry principal must be in a group that has rolebindings for the _schemas topic, preferably as ResourceOwner, which grants read, write, and manage permissions on subjects.