# 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](index.md#confluentsecurityplugins-sr-operations) against the subjects. It can be used independently or in conjunction with [Role-Based Access Control (RBAC)](../../../schema-registry/security/rbac-schema-registry.md#schemaregistry-rbac), as described below. ## Prerequisites - Activate the Schema Registry Security Plugin: ```text resource.extension.class=io.confluent.kafka.schemaregistry.security.SchemaRegistrySecurityResourceExtension ``` - You must have some form of authentication in place. For details, refer to [Authentication Mechanisms](../install.md#sr-security-plugin-authentication-mechanisms) or [HTTP Basic Authentication for Schema Registry](../../../security/authentication/http-basic-auth/overview.md#basic-auth-sr). ## Enable ACL Authorizer Set the `java.security.auth.login.config` system property. ```bash 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: ```bash 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)](../../../schema-registry/security/rbac-schema-registry.md#schemaregistry-rbac), then specify the `RbacAndAclAuthorizer` config in the Schema Registry config file as follows : ```bash 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: ```bash 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 REQUIRED: Schema Registry properties file -o, --operation 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 Subject to which the ACL is being applied to. Only applicable for SUBJECT operations. Use * to apply to all subjects -t, --topic 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 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`. ```bash ./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`. ```bash ./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`. ```bash ./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. ```bash ./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 (`*`). ```bash ./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 (`'*'`). ```bash ./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](../../../security/authorization/rbac/authorization-acl-with-mds.md#using-acls-mds).) 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. ```bash sr-acl-cli --config -add -s 'svc*' -p -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-`. ```bash sr-acl-cli -add --config /etc/kafka/acl-schema-registry.properties -o SUBJECT_READ:SUBJECT_WRITE:SUBJECT_COMPATIBILITY_READ -t 'dev-*' -p user ``` ### ACLs for subjects in non-default contexts [Schema contexts](../../../schema-registry/schema-linking-cp.md#schema-contexts) scope subject names within an independent namespace. A subject in a non-default context has a qualified name of the form `:.:`, such as `:.mycontext:transactions`. Pass the qualified name as the `-s` argument to set an ACL on a context-scoped subject. Quote the value so the shell doesn’t interpret the colons or asterisks. The following command adds `SUBJECT_WRITE` access to `transactions` in the `.mycontext` context for principal `Bob`: ```bash ./bin/sr-acl-cli --config ./etc/schema-registry/schema-registry.properties --add -s ':.mycontext:transactions' -p Bob -o SUBJECT_WRITE ``` The following command grants `schema-admin` `SUBJECT_WRITE` on every subject in `.mycontext` by using the context wildcard: ```bash ./bin/sr-acl-cli --config ./etc/schema-registry/schema-registry.properties --add -s ':.mycontext:*' -p schema-admin -o SUBJECT_WRITE ``` The ACL Authorizer matches qualified subject names verbatim. An ACL on `transactions` doesn’t grant access to `:.mycontext:transactions`, and vice versa. #### NOTE Available in Confluent Platform 8.2 and later. Response-side authorization for unqualified subject lookups is controlled by `confluent.schema.registry.context.authorization.enabled`, which defaults to `true`. When this check is enabled, a request that resolves to a subject in a non-default context returns `403 Forbidden` if the principal lacks `SUBJECT_READ` on the qualified subject. To exempt principals such as administrators, list them in `confluent.schema.registry.context.authorization.excluded.principals`. ### 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` ```bash ./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. ```bash ./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](../../../schema-registry/fundamentals/index.md#sr-subjects-topics-primer), you must specify the following ACLs on the internal schemas topic (default topic name is `_schemas`): ```bash 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.