.. _confluentsecurityplugins_schema_registry_authorization: Operation and Resource Support for |sr| in |cp| =============================================== The |sr| security plugin provides authorization for operations on schemas for :ref:`subjects`, which correspond to |ak| topics. The supported operations and corresponding Schema Registry URIs are listed here. These apply to both |rbac-long| and ACL authorization. .. include:: ../../../schema-registry/includes/rbac-acls-tip.rst .. _confluentsecurityplugins_sr_operations: Supported Operations -------------------- ================================ ============================================================================= SCHEMA REGISTRY OPERATION RESOURCE ================================ ============================================================================= SUBJECT_READ .. http:get:: /subjects/(string: subject)/versions .. http:post:: /subjects/(string: subject) .. http:get:: /subjects/(string: subject)/versions/(versionId:version) SUBJECT_WRITE .. http:post:: /subjects/(string: subject)/versions .. http:post:: /compatibility/subjects/(string: subject)/versions/(versionId: version) SUBJECT_DELETE .. http:delete:: /subjects/(string: subject)/versions/(versionId: version) .. http:delete:: /subjects/(string: subject) SCHEMA_READ .. http:get:: /schemas/ids/{int: id} SUBJECT_COMPATIBILITY_READ .. http:get:: /config/(string: subject) .. http:get:: /mode/(string: subject) SUBJECT_COMPATIBILITY_WRITE .. http:put:: /config/(string: subject) .. http:delete:: /config/(string: subject) .. http:put:: /mode/(string: subject) .. http:delete:: /mode/(string: subject) GLOBAL_COMPATIBILITY_READ .. http:get:: /config and .. http:get:: /mode GLOBAL_COMPATIBILITY_WRITE .. http:put:: /config and .. http:put:: /mode GLOBAL_READ .. http:get:: /subjects ================================ ============================================================================= For more information on these operations, see the :ref:`Schema Registry API`. Example ACL Setups ------------------ Any "one size fits all" recommendation for |sr| ACL configurations will not make sense, but here are a few prosaic examples that may provide a starting point as you plan your deployment. - One permissive setup might be to provide all READ-ACLs to all clients, including ANONYMOUS. If you adhere to the need-to-know principle more closely, you may want to limit READ operations. - An autonomous team would need all the SUBJECT ACLs: READ, WRITE, DELETE, COMPATIBILTY_WRITE and COMPATIBILTY_READ. The exact configuration depends on the autonomy of the team and the desired level of control over the |sr|. A CD/CI system would get the same ACLs for all relevant subjects. - An admin team may additionally set up the ``GLOBAL_`` ACLs. To learn more about defining ACLs, see :ref:`confluentsecurityplugins_sracl_authorizer`. Configure the Authorizer ------------------------ Incoming requests are mapped to a Schema Registry Operation as outlined in above table, after which the request is authorized using the configured authorizer. ------------------------------------------ confluent.schema.registry.authorizer.class ------------------------------------------ The implementation used to authorize |sr| requests. This needs to be an implementation of the ``SchemaRegistryAuthorizer`` interface. * Type: string * Default: "" * Importance: high These |sr| authorizers are provided natively. - :ref:`Role-Based Access Control ` - :ref:`confluentsecurityplugins_sracl_authorizer` - :ref:`confluentsecurityplugins_topicacl_authorizer` Suggested Reading ----------------- * :ref:`schemaregistry_security` * :ref:`schemaregistry_api` * :ref:`schemaregistry_using`