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.
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.
Activate the Schema Registry Security Plugin:
You must have some form of authentication in place. For details, refer to Authentication Mechanisms or HTTP Basic Authentication for Schema Registry.
Enable ACL Authorizer¶
java.security.auth.login.config system property.
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.
Add the following config to the Schema Registry config file:
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 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
- 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_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
Below are various examples of adding to Schema Registry ACLs.
These examples assume you are running these commands from the home directory of your Confluent Platform installation.
Add write access to subject
./bin/sr-acl-cli --config ./etc/schema-registry/schema-registry.properties --add -s test-subject-value -p Bob -o SUBJECT_WRITE
Add write access for subjects
./bin/sr-acl-cli --config ./etc/schema-registry/schema-registry.properties --add -t test-subject -p Bob -o SUBJECT_WRITE
Add read and write access to subject
./bin/sr-acl-cli --config ./etc/schema-registry/schema-registry.properties --add -s test-subject-value -p Bob -o SUBJECT_WRITE:SUBJECT_READ
Aliceto 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
Tedto 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
Create an admin user
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¶
Confluent Platform 6.1.0 and later supports prefixed ACLs 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
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
sr-acl-cli -add --config /etc/kafka/acl-schema-registry.properties -o SUBJECT_READ:SUBJECT_WRITE:SUBJECT_COMPATIBILITY_READ -t 'dev-*' -p user
Remove ACL command is similar to that of add ACL, except that you ue the option
Remove write access to subject
test-subject-value for user
./bin/sr-acl-cli --config ./etc/schema-registry/schema-registry.properties --remove -s test-subject-value -p Bob -o SUBJECT_WRITE
This command lists all ACLs that have been defined.
./bin/sr-acl-cli --config ./etc/schema-registry/schema-registry.properties --list
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
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.
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
_schemas topic, preferably as
ResourceOwner, which grants read, write, and manage permissions on subjects.
- See Role Mappings to Operations for Subject Based Authorization for more about Schema Registry and RBAC.
- See Authorization using ACLs for more about ACLs.