System endpoint should also be accessible to user with admin roles
As per initial design, there was a need for reserved partition to store SHARED schemas so that users can share schemas across partitions. For example, boostrapped schemas can be accessed by any user from any partition. This design does not restrict users to create and share their schemas directly rather going through the bootstrapping route.
Initially, creation of all the schemas were through common PUT/POST endpoint and the decision of whether schema is SHARED or INTERNAL was decided based on the data-partition-id mentioned in the header. This design had its own challenges:
- Necessity of maintaining dedicated partition which all end users must be aware about
- Due to common endpoint for both SHARED and INTERNAL schemas, the decision making was driven through the data-partition-id in the header.
- Could not put any governance at the URL level for better access management.
Considering above challenges separate system endpoint was introduced to bifurcate INTERNAL and SHARED schema creation. Which means SHARED schemas can only be created using system endpoint without specifying any data-partition-id. This, however, was a breaking change and hence it was achieved in two phases:
-
Creation of System partition: At this stage, only system partition was introduced without impacting the user experience. As a result, all existing SHARED partitions were moved to system partition and new requests were re-directed to system partitions i.e no new SHARED schemas were getting created into reserved partition (default)
-
Introduction of new endpoint (https://{{domain}}/api/schema-service/v1/schemas/system): Because of a dedicated endpoint, SHARED schemas are created without providing any data-partition-id in the header.
But there is a issue with this design, it is always expected to create SHARED schemas only through bootstrap script which uses service principal. As a result of this, users who were previously able to create and share their schemas are impacted. They now only need to go through bootstrapping process.
To fix this, we need to restrict the access to this endpoint through some entitlement service group role like service schema-service.admin.