Sometimes, when a new feature is announced, it’s in fact hiding bigger changes on the entire environment. This is exactly what happens with these Workspace Identity and Resource Instance Rules.

The announcement: We can create OneLake shortcut to an Azure Storage Account protected by the Storage Account firewall.

This seems to be a very specific feature, interesting, but for very specific scenarios. Why does it deserve more attention?

This feature hides two huge improvements which will have a way broader effect: Workspace Identities and Resource Instance Rules.

Workspace Identities

The feature seems simple: We can set an Azure identity to the Workspace.

Configuring the Workspace Identity

This feature opens many possibilities: Everything scheduled, notebooks, dataflows, pipelines, can run using the identity of the workspace instead of user identities.

The access to resources can be safer and the resources, such as notebooks and pipelines, can be broken down in multiple workspaces according to the identities and permissions they need.

Resource Instance Rules

This is a new feature we can apply on resource firewalls, starting with storage accounts.

Blocking the access based on IPs of virtual networks may be difficult. The possibility to block access based on the managed identity of a resource makes the security much more granular, and the environment much safer.

Azure only supports this feature in storage accounts. However, I could bet soon we will see the same feature in other resources as well.

Resource Instance Rules on Storage Accounts Network Configuration

I have videos about security where I explain that choosing the option “Allow access to Azure Resources” is something that should never be done.

The difficulties to filter the access by Ip or Virtual Network ends up making the developer choose this bad option. Not anymore. The storage can filter the access by Resource Managed Identity.

Joining the Pieces

The entire set of the two features, now, makes exactly what it promises: Allows a shortcut from Fabric to access an Azure Storage in a secure way.

The secret is to look beyond the current result and check what’s coming next.

The Future

These two features create a clear expectation for each environment.

Fabric: On Fabric we expect other Fabric objects, such as Notebooks, Pipelines and Dataflows, to support access to resources using the workspace identity.

Azure: On Azure we expect the filter by managed identity to be extended to the network configuration on all the resources, not only storage accounts.