Workspace Identity and Resource Instance Rules: More than simple features

Comments 0

Share to social media

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.

A white paper with black text

Description automatically generated

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.

A screenshot of a computer screen

Description automatically generated

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.

 

Load comments

About the author

Dennes Torres

See Profile

Dennes Torres is a Data Platform MVP and Software Architect living in Malta who loves SQL Server and software development and has more than 20 years of experience. Dennes can improve Data Platform Architectures and transform data in knowledge. He moved to Malta after more than 10 years leading devSQL PASS Chapter in Rio de Janeiro and now is a member of the leadership team of MMDPUG PASS Chapter in Malta organizing meetings, events, and webcasts about SQL Server. He is an MCT, MCSE in Data Platforms and BI, with more titles in software development. You can get in touch on his blog https://dennestorres.com or at his work https://dtowersoftware.com