topic Best practice to enforcing row-level security across multiple catalogs sharing same schema structure in Data Engineering

Best practice to enforcing row-level security across multiple catalogs sharing same schema structure

Khasim_1 — Fri, 18 Sep 2026 17:43:48 GMT

Hi Everyone,

We have identical schema structures replicated across three catalogs (dev, qa, prod) to support environment isolation. We now need to apply row-level security (e.g., restricting sales reps to only see their own region's data) consistently across all three catalogs without duplicating the row-filter function/logic three times.

What we've tried: > - Created a single row-filter function in a shared "utility" catalog and attempted to reference it from the other catalogs — this failed due to cross-catalog function reference limitations. > - Considered duplicating the filter function per catalog, but this creates a maintenance burden (any logic change requires updating 3 places).

Questions:

Is there a supported pattern for sharing row-filter/column-mask functions across catalogs in Unity Catalog, or must each catalog maintain its own copy?
Does Unity Catalog support catalog-level inheritance of security policies, or is row/column security always scoped strictly to the catalog where the function is defined?
Has anyone solved this using Databricks Asset Bundles (DABs) to templatize and redeploy the same filter logic across catalogs, rather than trying to share a single function reference?

Any real-world patterns for maintaining DRY (Don't Repeat Yourself) security policies across multiple catalogs would be appreciated.

Re: Best practice to enforcing row-level security across multiple catalogs sharing same schema struc

ThomazNeto — Sun, 20 Sep 2026 12:07:49 GMT

Hi Khasim,

Look at ABAC policies instead. That is the feature Databricks built for exactly this.

With ABAC you write the row filter UDF once, tag the tables (governed tags are account-level, so the same taxonomy applies across all your catalogs), and attach a policy at the catalog level. The docs say a policy attached at a catalog "evaluates against all securables of that type within that catalog", and tags set on the catalog or schema are inherited by the tables when policies are evaluated. Even better for your case: you can attach the policy ON METASTORE, which the docs describe as applying "across every catalog in the metastore". That option is still in Beta and needs a metastore admin, but it collapses your problem to one UDF plus one policy. If you'd rather stay out of Beta, it's one UDF plus three one-line CREATE POLICY statements, one per catalog, all pointing at the same fully-qualified function. The requirement listed is just EXECUTE on that UDF.
https://docs.databricks.com/aws/en/data-governance/unity-catalog/abac/
https://docs.databricks.com/aws/en/data-governance/unity-catalog/abac/policies
https://docs.databricks.com/aws/en/data-governance/unity-catalog/abac/core-concepts

On your question 2: table-level row filters and masks are properties of each table, there is no inheritance. Inheritance is what ABAC adds (catalog, schema, or metastore scope). The docs also recommend attaching policies "at the highest applicable level, usually the catalog".

On the cross-catalog failure you hit: I couldn't find anything in the docs saying the filter function has to live in the same catalog as the table. What they do require is EXECUTE on the function, USE SCHEMA on its schema and USE CATALOG on its catalog, and the Catalog Explorer dialog explicitly lets you pick the function's catalog and schema. Worth checking the exact error message, it may have been a privilege on the utility catalog rather than a hard limitation.
https://docs.databricks.com/aws/en/data-governance/unity-catalog/filters-and-masks/manually-apply

On bundles: there is no UC function or policy resource type in bundles today (schemas, volumes, secrets, yes; functions and policies, no), so the templating approach means a SQL task in a job with ${var.catalog} running CREATE OR REPLACE FUNCTION and CREATE OR REPLACE POLICY per target. It works, but with ABAC you mostly don't need it anymore.
https://docs.databricks.com/aws/en/dev-tools/bundles/resources

Hope this helps.

Re: Best practice to enforcing row-level security across multiple catalogs sharing same schema struc

bijilsubhash — Sun, 20 Sep 2026 13:20:13 GMT

Agree with @ThomazNeto - only thing I would add is your point 3 requirement: you could also consider using Terraform instead DABs or job for managing the ABAC policies across multiple environments. It does not support the beta features i.e. metastore level policies.

https://registry.terraform.io/providers/databricks/databricks/latest/docs/resources/policy_info