如何在共享 Databricks metastore 中按环境隔离 catalog 和元数据？

2026-11-04数据阿明

结论

在同一个 metastore 中，可以使用 workspace-catalog binding 和 Unity Catalog 权限，实现环境之间的访问隔离，并限制常规元数据的可见性。不过，这是共享治理服务内的逻辑隔离，无法保证“只要无法访问 PRD VNet，就无法获知任何 PRD 元数据”。

如果 DEV / QAT / PRD 需要各自独立的 metastore，就不能在同一个 Azure Databricks account 的同一 region 内按环境创建三个 metastore。官方限制是每个 account 在每个 region 中只能有一个 metastore；常规环境隔离主要以 catalog 为边界。官方 catalog 架构说明

为什么独立存储和 VNet 还不够？

现有方案将各环境的 workspace、VNet 和 ADLS Gen2 storage account 分开，为数据访问隔离提供了基础，但不能由此认定元数据也已隔离。

Unity Catalog metastore 是 Azure Databricks 控制平面中的区域性元数据与治理服务。catalog 的 managed storage location 用来存放托管表和卷，catalog 的全部治理元数据并不因此部署在对应的 ADLS account 或 VNet 中。Unity Catalog 架构设计

阻断对 PRD 存储的访问，也不代表已阻断通过 Catalog Explorer、SQL 元数据查询或 REST API 获取元数据的所有途径。workspace 入口、catalog 绑定和身份权限都需要分别控制。

同一 metastore 内如何实施隔离？

1. 将各环境 catalog 绑定到对应 workspace

建议为各环境的 catalog 和 workspace 建立明确映射，例如：

catalog	允许访问的 workspace
`dev_catalog`	DEV workspace
`qat_catalog`	QAT workspace
`prd_catalog`	PRD workspace

在 Catalog Explorer 的 catalog 页面打开 Workspaces，取消 All workspaces have access，再分配对应 workspace。

绑定限定了 workspace 的访问范围：即使用户拥有 PRD 表的 SELECT 权限，也无法从未绑定的 DEV workspace 访问该表。官方说明，绑定还会影响 information_schema、Catalog Explorer 和 lineage 的展示。workspace-catalog binding 文档

以下 CLI 示例假设 prd_catalog 已存在，prd-admin 是已配置的认证 profile，执行命令的身份有权修改绑定。运行前请将 workspace ID 替换为实际值：

databricks catalogs update prd_catalog \
  --isolation-mode ISOLATED \
  --profile prd-admin

databricks workspace-bindings update-bindings catalog prd_catalog \
  --json '{"add":[{"workspace_id":1234567890123456,"binding_type":"BINDING_TYPE_READ_WRITE"}]}' \
  --profile prd-admin

这两个命令是独立操作，应在变更窗口内连续执行。如果 catalog 已有其他绑定，还需检查并移除不符合环境要求的条目；add 不会自动清除已有绑定。

2. 单独收紧元数据权限

除绑定外，还要按环境划分 account-level groups 和 service principals，检查所有直接授权、组授权及继承授权。

特别注意：

BROWSE 允许发现对象和查看基本元数据，不需要 USE CATALOG 或 USE SCHEMA。
READ METADATA 可以暴露更完整的元数据，包括授权和部分安全配置，需要限制给可信身份。
只撤销 SELECT 并不能证明元数据已经不可见。

严格隔离场景下，不应直接采用向 All account users 开放 PRD BROWSE 的数据发现策略。Unity Catalog 权限说明

同时，还应检查 PRD 的 external locations、storage credentials 等对象的 workspace binding 和权限，不能只配置 catalog。

3. 明确认知管理员和所有者例外

官方明确指出，即使某些 catalogs 没有绑定当前 workspace，metastore admins 仍能看到 metastore 中的所有 catalogs，catalog owners 也能看到自己拥有的 catalogs。此时 catalog 可能显示为灰色，其子对象不可见、不可查询。绑定的可见性例外

如果要求非 PRD 网络中的管理身份连 catalog 名称都不能看到，共享 metastore 的绑定机制无法提供这样的保证。管理员、所有者以及能够修改授权的身份都应纳入隔离范围。

如何让网络边界参与控制？

Unity Catalog 的 catalog 授权与 workspace binding 不支持根据调用方所属 VNet 动态过滤 catalog。可以组合以下控制：

将 PRD catalog 仅绑定到 PRD workspace。
为 PRD workspace 配置入站 Private Link，并关闭公共网络访问，限制 Web UI 和 API 的入口。
仅允许批准的客户端网络到达相应 private endpoints，同时检查路由、DNS、peering 和代理路径。
保留 ADLS 的网络限制，并限制存储身份、密钥或其他可绕过 Unity Catalog 的直接访问方式。

Azure Databricks 区分入站、classic compute 到控制平面、serverless 出站等 Private Link 路径。已有 ADLS private endpoints 并不意味着这些路径都已受控；使用 serverless 时，还需单独评估其网络配置。Private Link 概念

验收条件应明确为“无法到达任何获准的 PRD 访问入口”，而不是仅根据客户端是否位于 PRD VNet 内作出判断。

什么时候需要不同 tenant 或 region？

可以按隔离要求选择：

要求	适合评估的方案
普通 DEV / QAT 身份不能访问或发现 PRD 数据对象	独立 workspace、catalog binding、最小权限和网络控制
环境之间不能共享 metastore	不同 region，或独立 account
同一区域内还要分离账户管理和身份治理边界	独立 Microsoft Entra ID tenants 对应的独立 accounts

Databricks 员工发布的环境隔离说明指出，Azure Databricks account 与 Microsoft Entra ID tenant 是一对一映射，不同 accounts 的 workspaces 不共享同一区域的 metastore。因此，仅拆分 Azure subscriptions、resource groups 或 VNets，不能获得独立 account 和 metastore。Databricks 环境隔离说明

不同 region 可以分离 metastore，但仍可能共享 account 管理权限。独立 tenant/account 可以进一步分离管理边界。无论采用哪种方案，仍需分别配置网络和授权；资源分开本身不能证明满足全部隔离要求。

如何验证方案是否达到要求？

部署后，使用实际普通用户和 service principal，分别从 DEV、QAT、PRD 以及未经批准的客户端网络验证：

Catalog Explorer、搜索和 REST API 是否暴露 PRD 对象。
SQL 是否能列出或访问 PRD 元数据。
PRD workspace 的公共入口是否已关闭，私有入口是否仅从批准网络可达。
管理员、catalog owners 和跨环境组成员是否存在预期之外的可见性。

可用以下 SQL 检查部分元数据路径：

SHOW CATALOGS;

SELECT catalog_name
FROM system.information_schema.catalogs
WHERE catalog_name = 'prd_catalog';

SHOW SCHEMAS IN prd_catalog;

这些查询用于验证当前身份和 workspace 下的行为，还需要检查 API、网络入口及管理员例外。如果要求“任何 PRD 元数据均不得跨环境可见”，应先明确要求是否包含管理身份和其他审计、日志入口，再决定是否采用独立 tenant/account。