Keep Databricks and Fabric permissions aligned with Policy Weaver

Mirroring a catalog does not mirror its security model.

Fabric can expose Azure Databricks Unity Catalog tables through a mirrored catalog and OneLake shortcuts, but Databricks permissions do not automatically become OneLake roles. A small environment can maintain both manually. A changing catalog with many groups, masks, and row filters needs a repeatable sync process.

Policy Weaver is Microsoft’s open-source accelerator for that job. It reads source permissions, maps supported policies, resolves principals, and writes OneLake data access roles for a mirrored item.

The important word is supported.

Where it fits

This continues Consume Azure Databricks Unity Catalog data in Fabric with shortcuts.

Unity Catalog grants, groups, masks, and row filters
        |
        v
Policy Weaver
        |
        +--> resolve effective privileges
        +--> map supported constraints
        +--> resolve Entra principals
        |
        v
OneLake data access roles on the mirrored catalog

Policy Weaver does not copy data and does not replace the mirrored catalog. It syncs policy intent where the two policy languages overlap. The repository also contains Snowflake and Dataverse connectors; Dataverse is described as beta.

What the Databricks connector can do

It can:

• inspect Unity Catalog privileges and inherited access;
• account for nested group membership;
• map table access into OneLake scopes;
• create roles per group or table;
• translate supported column masks and row filters;
• apply a grant or deny fallback when translation is unsupported; and
• write the resulting roles to the Fabric item.

For security automation, start with deny for unsupported rules. A translation that silently grants broader access is a bad surprise.

Role-based or table-based mapping?

Use role_based when row-level or column-level security is required. Column security and row security require that mapping mode.

Prerequisites

Fabric:

1. a capacity-backed workspace;
2. a Mirrored Azure Databricks catalog;
3. OneLake security enabled;
4. a service principal as workspace Admin;
5. service principals allowed to call Fabric public APIs; and
6. item access for users and groups assigned to roles.

Databricks:

• Entra-synchronized account users and groups;
• access for the Policy Weaver identity to read security metadata;
• the repository’s documented service-principal setup; and
• careful treatment of the Account Admin and OAuth secret requirements.

Principal resolution may require Microsoft Graph User.Read.All application permission. Grant only what the selected connector needs.

The enforcement checks people miss

Generated roles in the UI are not proof of enforcement.

The SQL analytics endpoint must use User’s identity access mode:

1. open Security;
2. open View data access mode;
3. select User’s identity access mode; and
4. apply it.

Delegated identity mode ignores OneLake roles and uses SQL permissions. Recreating the mirrored item can reset this setting.

Governed consumers should normally be Viewers. Admins, Members, and Contributors bypass OneLake security. A group in a OneLake role also needs Fabric access to the item or workspace.

1. Install the package

Policy Weaver requires Python 3.11 or later:

pip install policy-weaver

Pin and test the version for repeatable automation. Validate the beta project against a non-production mirrored catalog.

2. Protect credentials

Do not commit secrets, tokens, or tenant-specific credentials. Use Key Vault secret names in configuration. In a Fabric notebook use fabric_notebook authentication; outside Fabric, the project supports Azure CLI authentication.

3. Start with a narrow configuration

keyvault:
  use_key_vault: true
  name: my-policy-weaver-vault
  authentication_method: fabric_notebook

fabric:
  mirror_id: "<mirrored-catalog-item-id>"
  mirror_name: "sales_catalog"
  workspace_id: "<fabric-workspace-id>"
  tenant_id: "<entra-tenant-id>"
  fabric_role_suffix: "PW"
  delete_default_reader_role: true
  policy_mapping: role_based

constraints:
  columns:
    columnlevelsecurity: true
    fallback: deny
  rows:
    rowlevelsecurity: true
    fallback: deny

service_principal:
  client_id: "kv-policy-weaver-client-id"
  client_secret: "kv-policy-weaver-client-secret"
  tenant_id: "kv-policy-weaver-tenant-id"

source:
  name: "sales_catalog"
  schemas:
    - name: "sales"
      tables:
        - "orders"
        - "customers"

type: UNITY_CATALOG

databricks:
  workspace_url: "https://adb-xxxxxxxxxxxxxxxx.x.azuredatabricks.net/"
  account_id: "<databricks-account-id>"
  account_api_token: "kv-databricks-oauth-secret"

delete_default_reader_role: true can remove broad default access. Use it only after testing that every intended role is generated and assigned.

4. Run the synchronization

from policyweaver.weaver import WeaverAgent
from policyweaver.plugins.databricks.model import DatabricksSourceMap

config = DatabricksSourceMap.from_yaml("/lakehouse/default/Files/policy-weaver/config.yaml")

await WeaverAgent.run(config)

The run applies the current source state. It is not a continuous control plane, so schedule it through a job, pipeline, or notebook. Serialize runs against the same role set.

5. Test access, not only role creation

Use at least two restricted Viewer identities:

1. one that should read a selected table;
2. one that should be denied or see a restricted subset.

Verify:

• roles and principals;
• allowed and denied queries;
• masks and row filters;
• unsupported-policy reports and fallbacks;
• source-grant removal after the next synchronization; and
• that no Admin, Member, or Contributor account was used as the enforcement test.

A role that looks correct in the UI but was tested only by a workspace Admin is not tested.

6. Operate it as security automation

• pin the package;
• keep secret-free configuration in source control;
• retrieve credentials from Key Vault;
• schedule and alert on failures;
• archive source and generated policy snapshots where appropriate;
• review unmapped policies; and
• rerun restricted-identity tests after endpoint or mirror changes.

Snapshot hooks support audit workflows, but the normal WeaverAgent.run path still applies policy state. A test item is safer than assuming snapshots are a dry run.

Important limitations

• unsupported expressions require a fallback decision;
• local Databricks workspace groups are not the supported identity model;
• table-based mapping cannot express column security;
• enforcement depends on item access and endpoint identity mode;
• elevated workspace roles bypass OneLake security;
• recreating the mirrored item can reset endpoint settings;
• source changes take effect only when synchronization runs; and
• the project is an open-source accelerator without warranty.

Policy Weaver reduces repetitive administration. It does not replace policy design, least-privilege review, restricted-identity tests, or monitoring.

When I would use it

Use it when Unity Catalog is the source of truth, the same governed data is consumed in Databricks and Fabric, and supported policies cover the main access patterns. Keep manual roles when the dataset is small, access is stable, or the source relies heavily on expressions that cannot be mapped safely.

Source and further reading

• Microsoft Policy Weaver on GitHub
• Policy Weaver configuration and connector guidance
• Get started with OneLake security
• Mirror an Azure Databricks catalog in Fabric
• Configure Entra ID SCIM for Unity Catalog

If the accelerator is useful, star the Policy Weaver repository and use its issue tracker for product-specific questions.