🔐Security in a shared workspace

Well, why?… perhaps you prefer not spinning more resources to segmentate the environment or decouple the workloads, but you still need to enforce data security across domains.

Lets look at how to secure an HR container in a shared Azure Synapse Analytics workspace that serves mixed workloads by using only RBAC permissions at the storage, and at container level.

It’s recommended to use a separate storage account. I will explain and demo why.

DISCLAIMER: This is provided for illustration purposes only, “as is” without warranty of any kind, either expressed or implied, and its not intended to be used in a production environment. This does not validate a secure implementation on behalf of Microsoft or myself. You assume the risks if you implement it.

AAD groups:

  • HR
  • Finance

AAD users:

  • dev1 member of Finance only
  • dev2 member of Finance only
  • hrdev3 member of HR only
  • hrdev4 member of HR only
  • hiram (global admin)

Synapse workspace: (permissions applied via the studio Access Controls)

synapsehiram

Granted both AAD groups Synapse Administrators via the Studio > Manage > Access control. Note, this should be refined due to Linked Services and Pipelines mixed workloads concern, but for now I am just testing the Storage Container access.

Storage Account:

  • lakehiram (Primary ADLS gen2) – added Storage Blob Data Contributor role assignment to AAD group HR only.

Containers of Primary ADLS gen2 Storage Account:  (permissions assigned via IAM – RBAC per container)

  • lakehiram container (primary FS) – granted Finance access control (IAM) role assignment Storage Blob Data Contributor, HR group inherits from Storage level.
  • hrdata container – HR group inherits from storage level.

In general, permissions can take at least 5 minutes to apply and in some cases I had to sign-out of & sign-in to the workspace studio by manually specifying the workspace name in a private browser session. The AAD users above do not have access to traverse the Azure subscription resources.

Testing:

As Admin – Hiram.

As HR devs  – able to query HRdata and explore.

As Finance devs – cannot query HRdata container content, but cannot access primary storage account either.  

Unable to browse other containers, including primary FS – This is a problem due to role access assigned.

Granting Storage Blob Data roles at the storage account level would leak access to HRdata container due to inheritance which cannot be removed at the child container. Therefore, a sperate storage account to host the HRdata container is recommended.

Finance devs are able to still query Primary FS lakehiram but unable to explore it.

This hinders Azure Synapse Analytics workloads.

References:

How Permissions are Evaluated

How Access is Evaluated

Thanks,

Hiram

One thought on “🔐Security in a shared workspace

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.