Azure Machine Learning Datastore differentiations:

This is probably going to be an easy read compared to the previous articles referenced below. The problem an az ml workspace administrator wants to tackle is create different datastore objects so that user A gets one datastore but not others and user B gets another datastore but not others. Permissions are granted by roles and both users A and B have custom roles that have granted the permission to read the datastores with the following enumeration:

-          Microsoft.MachineLearningServices/workspaces/datastores/read

 

This permission does not say Datastore1/read but not Datastore2/read. In fact, both users must get the generic datastores/read permission that the cannot do without. Access controls cannot be granted to datastores as they can be given to files.

The solution to this problem is fairly simple. There are no datastores created by the administrator. Instead, the users create the datastores programmatically passing it either the Shared-Access-Signature Token to an external data storage or an account key. Either way, they must have access to their storage-account/container/path/to/file and can create the SAS token at their choice of scope.

The creation and use of datastores are just like that of credentials or connection objects required for a database. As long as the users manage it themselves, they can reuse it at their will.

If the administrator must be tasked with isolating access to the users to their workspace components and objects, then two workspaces will be created and assigned to groups to which these users can subscribe individually.

If we refer to the copilots for information on this topic, it will be a false positive that custom roles and Role-based Access Control will solve this for you. It will not be wrong in asserting “By properly configuring RBAC, we can control access to datastores and other resources within the workspace” but it is simply not recognizing that the differentiation is being made to the objects of the same kind. That said, there will be a full commentary on the other mechanisms available that include

Role-based Access Control, access control at external resource, generating and assigning different SAS tokens as secrets, generating virtual network service endpoints, exposing datastores with fine-grained common access, or using monitoring and alerts to detect and mitigate potential security threats. It is also possible to combine a few of the above techniques to achieve desired isolation of user access.

Previous articles: IaCResolutionsPart81.docx