This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.
With Synapse workspaces, you can create tables in the managed spark clusters within the workspace. As a native feature of the product, these tables are synchronously replicated to the managed SQL serverless endpoint within the same workspace.
This allows a familiar SQL interface and the ability to manage such SQL-like objects using the familiar SQL server vocabulary.
This feature is well documented here and I would encourage you to have a read-through of this capability before reading any further on the shortcomings of this feature/probable solution of the limitation described below.
Managed and external spark tables are automatically synced with serverless SQL endpoint in the same workspace. The creator of this table can query this table using the synapse spark using their preferred SDK i.e. scala, python, SQL, and C# .NET.
Once this table is synced with the serverless endpoint it has been found that the creator of this table (who are not synapse administrator or even synapse SQL administrator) are not able to access this table despite them having access to underlying storage i.e. as a data reader role or even a data contributor role.
If you attempt to query this shared table from SQL serverless (for example - a table named permissiontable created in Synapse Spark) you'll get an error response back -
External table 'permissiontable' is not accessible because content of directory cannot be listed.
It has been found that users who are synapse administrators or even synapse SQL administrators with access to underlying storage are able to access the synced tables.
This further prohibits collaboration i.e. analytical objects created in the workspace using synapse spark cannot be recycled or reused by other individuals or applications which are not privileged users as a sysadmin i.e. who are not synapse administrators or even synapse SQL administrators on the workspace.
Any attempt to create a contained database user fails as the shared and replicated databases are marked as read-only and hence do not permit the creation of additional roles/users in them to govern access.
In hindsight, it must be noted that there is no server-level read-only role that would have allowed access to such replicated/shared databases as described above, the database level roles aren’t supported in such shared databases to regular synapse users via any role assignment workflows.
Let’s first talk about few CONTROL SERVER permissions which were introduced with SQL Server 2014 –
*CONNECT ANY DATABASE -
CONNECT ANY DATABASE is simple server-level permission that provides access to all current and future databases. It does not grant any permission in any database beyond the ability to connect, but when combined with other permissions, you can allow very important business security needs to be met with ease.
SELECT ALL USER SECURABLES -
This permission allows the grantee access to query (read only) the database objects and the tables within.
*This assumes that the user/application is not a sysadmin (i.e. synapse admin or synapse sql admin) on this workspace.
You can find more information about these permission grants here - https://docs.microsoft.com/en-us/sql/t-sql/statements/grant-server-permissions-transact-sql?view=sql-server-ver15#remarks
You can also use the sys tables i.e. server_permissions to audit list of logins who have been granted explicit roles on the serverless endpoint with such grants.
Summarizing this post now, these two permissions grant the users/applications can now access to the shared databases/tables which are sync’ed with SQL serverless in Synapse workspace. This is suited where application teams would not want to grant explicit sysadmin grants to query such shared databases/tables.