.. _confluentsecurityplugins_sracl_authorizer: |sr| ACL Authorizer for |cp| ============================ |sr| ACL Authorizer is a fine-grained authorizer which relies on ACLs defined for specific :ref:`Schema Registry Operations ` against the subjects. It can be used independently or in conjunction with :ref:`Role-Based Access Control (RBAC) `, as described below. .. tip:: - |sr| ACL Authorizer does not support schema exporters. To implement access control on exporters, use |rbac| as described in :ref:`cp-schema-linking-rbac`. - SCHEMA_READ is the only operation that cannot be defined and managed explicitly through ACLs with the |sr| ACL Authorizer. It relies on SUBJECT_READ grant on at least one of the subjects that the schema ID is associated with. Prerequisites ------------- - Activate the |sr| Security Plugin: .. code-block:: text resource.extension.class=io.confluent.kafka.schemaregistry.security.SchemaRegistrySecurityResourceExtension - You must have some form of authentication in place. For details, refer to :ref:`sr_security_plugin_authentication_mechanisms` or :ref:`HTTP Basic Authentication for Schema Registry `. Enable ACL Authorizer --------------------- Set the ``java.security.auth.login.config`` system property. .. include:: ../../../includes/sracl-env.rst .. note:: If you've already configured ``kafkastore.sasl.jaas.config`` in your |sr| properties file (``/etc/schema-registry/schema-registry.properties``) to run the |sr| ACL CLI tool, then ``SECURITY_PLUGINS_OPTS`` is not required. In this case, the |sr| properties file already includes all the information required to communicate with the |ak| broker, including security credentials. --------------------- Enable for ACLs only --------------------- Add the following config to the |sr| config file: .. codewithvars:: bash confluent.schema.registry.authorizer.class=io.confluent.kafka.schemaregistry.security.authorizer.schemaregistryacl.SchemaRegistryAclAuthorizer You can manage the |sr| ACLs through the |sr| ACL CLI tool and the ACLs stored in a separate topic based on the configuration shown below. The |sr| ACL CLI communicates directly to the |ak-tm| brokers in the |sr| properties. For a secure broker with ACLs, you should use the CLI directly from the |sr| 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 :ref:`Role-Based Access Control (RBAC) `, then specify the ``RbacAndAclAuthorizer`` config in the |sr| config file as follows : .. codewithvars:: bash confluent.schema.registry.authorizer.class=io.confluent.kafka.schemaregistry.security.authorizer.RbacAndAclAuthorizer .. include:: ../../includes/configuration.rst :start-line: 2 :end-line: 10 |sr| ACL CLI ------------ |sr| ACLs can be managed through |sr| ACL CLI tool. Run the |sr| ACL CLI tool to view the available options: .. code:: 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 |sr| ACLs. .. important:: These examples assume you are running these commands from the home directory of your |cp| installation. #. Add write access to subject ``test-subject-value`` for user ``Bob``. .. codewithvars:: bash ./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`` and ``test-subject-value`` for user ``Bob``. .. codewithvars:: bash ./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 user ``Bob``. .. codewithvars:: bash ./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. .. codewithvars:: 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 #. Allow user ``Ted`` to read, write, and manage global compatibility for topics prefixed with ``dev-``, using the wildcard (``*``). .. codewithvars:: bash ./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 (``'*'``). .. codewithvars:: 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 |ak| ACLs support. (See, for instance, :ref:`using-acls-mds`.) For example, the following would match all subjects in |sr| with names starting with ``svc`` and give the principal SUBJECT_WRITE permissions on those subjects. .. codewithvars:: 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-``. .. codewithvars:: bash 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`` .. codewithvars:: 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. .. codewithvars:: bash ./bin/sr-acl-cli --config ./etc/schema-registry/schema-registry.properties --list Required ACLs ------------- In addition to defining access privileges for principals to :ref:`topics and subjects`, you must specify the following ACLs on the internal schemas topic (default topic name is ``_schemas``): .. code:: 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, |sr| 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 |rbac-long|, the |sr| 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 :ref:`sr-role-mappings` for more about |sr| and |rbac|. - See :ref:`kafka_authorization` for more about ACLs.