Advice regarding retaining environment-specific access when applying Unity Catalog to workspaces split by environment

[Kayl669]

My org is considering a transition from hive metastore to unity catalog. We currently have a workspace for each of dev/uat/production and each of those provide access to their respective blob storage account data. Unity Catalog sits at the account-level and bridges the workspaces; which seem to enable a user (with justifiable access to all envs) to access prod data from any workspace as there doesn't seem to be a way to deny a user the ability to switch catalog (or even set what the default catalog is) within a particular workspace. How can we steer/force users to use each environment-specific workspace as intended?

[LandanG]

Hi @James H​ ,

I believe you're describing something that will be addressed with a feature called "Catalog to workspace bindings". For example, only prod data can be accessed in prod workspaces. This feature is slated to be released hopefully by the end of January

[4kb_nick]

This would be really great. I’m helping a client build a new lakehouse in Azure and this is one of the only things I’m stuck on with the proposed architecture. Catalog to workspace binding would really solve that problem.

in the interim, is there any way to leverage cluster policies to force the default catalog on a cluster and prevent the user from changing it?

[js54123875]

Hi @Landan George​ - Is "Catalog to workspace bindings" available? I cannot find any documentation on it.

[Debayan]

Hi, Please refer : https://docs.databricks.com/data-governance/unity-catalog/manage-privileges/index.html and let us know if this helps.

[Kayl669]

I did find this document which indicates that you can set the initial catalog on cluster start:: https://learn.microsoft.com/en-us/azure/databricks/data-governance/unity-catalog/hive-metastore#diff...