Important

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

Schema Registry ACL Authorizer

Schema Registry ACL Authorizer is a fine-grained authorizer which relies on ACLs defined for specific Schema Registry Operations against the subjects. The Schema Registry ACL Authorizer is the most definitive and complete way of defining ACL and authorization for Schema Registry.

Note

SCHEMA_READ is the only operation that cannot be defined and managed explicitly. It relies on SUBJECT_READ grant on at least one of the subjects that the schema ID is associated with.

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

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.

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

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.

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:

<path-to-confluent>/bin/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_SUBJECTS_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 & 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. 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 '*'

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.