Enterprise Unity Catalog RBAC model in Databricks

[APJESK]

I'm designing an enterprise Unity Catalog RBAC model in Databricks and would like feedback on whether this follows best practices.

My current design is:

• A single Service Principal is used by Terraform to provision all Unity Catalog objects.

• The Service Principal is a member of the Metastore Admin group.

• Using Terraform, the Service Principal:

  • Creates the Storage Credentials and External Locations.

  • Creates the Catalog, then transfers ownership to the appropriate Catalog Owner group.

  • Creates the Schema, then transfers ownership to the appropriate Schema Owner group.

• The Service Principal remains the automation identity, while business ownership is transferred to the respective owner groups.

My RBAC roles are:

• Metastore Admin

• Catalog Owner

• Schema Owner

• Schema Write

• Schema Read

Is this considered a good enterprise-scale design and aligned with Databricks Unity Catalog best practices?

Specifically:

1. Is it a best practice to use a single Terraform Service Principal that belongs to the Metastore Admin group for provisioning?

2. Should the Metastore Admin group continue to own Storage Credentials and External Locations, while Catalog and Schema ownership is transferred to the respective owner groups?

3. Are these RBAC roles sufficient for a large enterprise, or would you recommend adding or changing any roles?

[Lu_Wang_ENB_DBX]

Yes — this is a solid enterprise baseline. Your pattern matches Databricks guidance to automate UC with Terraform, use service principals for automation, and keep ownership / MANAGE narrowly assigned.

• Single Terraform SP in a Metastore Admin group: Yes, acceptable. Using a service principal for IaC is recommended, and Databricks explicitly allows metastore admin to be assigned to a user, service principal, or group; group-based assignment is strongly recommended.

• Would I keep that SP highly privileged forever? Only for central platform automation. Metastore admin is optional but highly privileged, so use it sparingly and prefer OAuth auth for the SP.

• Storage credentials + external locations owned by Metastore Admin / platform group: Yes, that’s the cleaner pattern. These are top-level metastore objects, and Databricks recommends limiting creation/management of external locations to admins or trusted data engineers because they are broad, high-impact objects.

• Catalog + schema ownership transferred to domain groups: Yes, good practice. Owners of catalogs and schemas can manage grants on child objects, and Databricks says catalog/schema admins should control downstream access while ownership should be assigned sparingly.

• Small improvement: transfer ownership of external locations (and ideally storage credentials) from the creator SP to a platform admin group, not leave them implicitly on the SP.

• RBAC roles: Your set is a good minimum: Metastore Admin, Catalog Owner, Schema Owner, Schema Write, Schema Read.

• For larger enterprises, I’d usually add/clarify one more role: Platform Storage Admin for storage credentials/external locations, even if today it is the same people as Metastore Admin. That gives cleaner separation of duties as you scale.

• Also remember Account Admin and Workspace Admin remain separate required admin layers outside your UC data roles.

Bottom line: Yes, good design. I would tweak: keep the single Terraform SP, but make its power come from a dedicated metastore-admin group, and make platform groups own storage credentials/external locations while domain groups own catalogs/schemas.

[DoTA]

There are 2 aspects to this, it really depends on the enterprise architecture and data governance standards that your company needs to follow. 

1. On the enterprise architecture, if your company is following medallion architecture, it is not wise to transfer the ownership back to the business owner, the SPP should still how accountable for the bronze, silver and golden layer. You should only transfer back the ownership on business layer (such as data marts if you have).

2. On the governance side, it really depends on the company context.

For some company such as mine, it is require for the Data Platform to be air-gapped as no privilage data (PII) is allow to be exported from the workspace, hence we are required to use advance feature to meet these requirement:

1. Such as the new feature exclusive group (b4 this it is seperate workspaces for sensitive and non-sensitive data).

2. Consideration of using ABAC.

Please ensure you look on both side before finalizing, as architectural decision doesnt make or break right away, it start breaking in the long run.