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.
Prerequisites¶
Activate the Schema Registry Security Plugin:
resource.extension.class=io.confluent.kafka.schemaregistry.security.SchemaRegistrySecurityResourceExtension
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¶
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
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
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.
Add write access to subject
test-subject-value
for userBob
../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
test-subject-key
andtest-subject-value
for userBob
../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
test-subject-value
for userBob
../bin/sr-acl-cli --config ./etc/schema-registry/schema-registry.properties --add -s test-subject-value -p Bob -o SUBJECT_WRITE:SUBJECT_READ
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
Allow user
Ted
to read, write, and manage global compatibility for topics prefixed withdev-
, 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
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¶
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
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.
- See Role Mappings to Operations for Subject Based Authorization for more about Schema Registry and RBAC.
- See Authorization using Access Control Lists (ACLs) for more about ACLs.