DataHub 搜索访问控制Search Access Controls实战指南用 View Entity 权限实现查询时结果过滤【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub本指南完整讲解 DataHub 的Search Access Controls搜索访问控制它基于View Entity查看实体权限在查询时过滤搜索结果让用户只能发现其被授权访问的实体实现「默认拒绝」的安全模型。读完本文你将掌握该功能的启用前提与生效边界、viewUnrestricted实体豁免机制的底层原理、schemaField 列级搜索的已知限制以及一套「两团队三域」从建域、建组到策略配置、验证效果的完整落地步骤。功能定位它是 DataHub Cloud 专属特性Search Access Controls 允许组织限制用户能通过搜索结果发现的实体。该特性使用View Entity权限基于访问策略Policies过滤搜索结果确保用户只能看到其被授权访问的元数据。:::note DataHub Core 部署 带查询时过滤query-time filtering的 Search Access Controls 是DataHub Cloud功能。在 OSSDataHub Core上设置VIEW_AUTHORIZATION_ENABLEDtrue只能实现实体页面门禁entity page gating不会在查询时过滤搜索。参见 Policies 指南中的 view-based access control 策略设计。 :::从 策略设计文档 中的对比表格可以更清晰地看到两种部署形态的能力差异部署形态启用方式生效范围DataHub Cloud启用 Search Access ControlsView Entity权限搜索结果在查询时被过滤DataHub CoreGMS 上设置VIEW_AUTHORIZATION_ENABLEDtrueView Entity Page权限实体页面门禁与可选的搜索结果后置掩码——不是Elasticsearch 查询下推核心概念View Entity 权限View Entity权限控制用户能否发现并访问某个实体。启用 Search Access Controls 后用户在搜索结果中只会看到被授予查看权限的实体用户无法通过直接 URL 访问受限实体访问控制一致地作用于搜索search、浏览browse与直接访问direct access三种途径。这种统一策略保证了无论用户以何种方式尝试发现或查看实体访问控制都会被一致地执行。默认行为未启用 Search Access Controls 时所有用户都能在搜索结果中看到所有实体不基于策略做任何过滤。启用之后搜索结果基于适用于该用户的策略进行过滤只有命中至少一条包含View Entity权限的策略的实体才会被返回由此形成「默认拒绝default deny」模型——必须显式授予权限才能看到任何实体。实体类型绕过视图检查Entity types that bypass view checks启用 Search Access Controls 后仍有部分实体类型会完全绕过视图授权无需 View Entity 授权即可出现在搜索结果中。其机制分两层基线baseline在entity-registry.yml中通过viewUnrestricted: true声明「精简基线」覆盖overlay可选的VIEW_UNRESTRICTED_ENTITY_TYPES仓库自带的 CSV整体替换该 CSV 时覆盖的是 application 覆盖层而不是 registry 基线外加VIEW_UNRESTRICTED_ENTITY_TYPES_ADD/VIEW_UNRESTRICTED_ENTITY_TYPES_REMOVE两个增删操作。增删覆盖会改变最终生效的默认列表。所有其他类型的实体默认受限。关键点最终生效的默认列表 原不受限 CSV减去已在entity-registry.yml中标记的类型。默认列表不包含document、schemaField、container——这些类型在视图授权开启时默认受限container已不再于 registry 中被标记为viewUnrestricted。除非你确实想绕过视图检查否则不要通过VIEW_UNRESTRICTED_ENTITY_TYPES_ADD把它们加回去。这些是 GMS 环境变量参见 Environment Variables 文档。同一份列表在 DataHub Core 部署中同样作用于VIEW_AUTHORIZATION_ENABLEDtrue时的核心视图授权——但那只是实体页面门禁 / 搜索结果后置掩码查询时搜索过滤仍是 DataHub Cloud 专属。相关破坏性变更细节见 updating DataHub。仓库中的配置与实现证据以上机制在当前仓库中有完整实现可对照配置入口metadata-service/configuration/src/main/resources/application.yaml的authorization.view配置块约 L102-L130authorization.view.enabled默认${VIEW_AUTHORIZATION_ENABLED:false}即默认关闭authorization.view.unrestrictedEntityTypes.value默认值即仓库内置 CSV——dataHubPolicy,dataProcess,dataHubIngestionSource,dataHubSecret,service,dataHubExecutionRequest,assertion,mlModelDeployment,dataHubAccessToken,test,inviteToken,versionSet,incident,erModelRelationship,application,semanticModel,metric,businessAttribute,dataContract,dataHubAction,dataHubConnection,platformResource,aiAgent,api,repository,agentSkilladd/remove分别对应VIEW_UNRESTRICTED_ENTITY_TYPES_ADD、VIEW_UNRESTRICTED_ENTITY_TYPES_REMOVE默认均为空配置注释明确写出 registry 基线覆盖的类型identity 类如corpuser/corpGroup、platform 类如dataPlatform、metadata 模型类如ownershipType/structuredProperty/form/role等并强调document/schemaField/container刻意不出现在默认列表中。registry 基线声明metadata-models/src/main/resources/entity-registry.yml中大量实体声明了viewUnrestricted: true例如第 1-15 行的dataPlatform与role。解析与合并逻辑metadata-io/src/main/java/com/linkedin/metadata/search/utils/EntityTypeUtils.java的resolve(ViewUnrestrictedEntityTypes, EntityRegistry)方法实现了「registry 基线 → value 覆盖层 → add/remove 增删」的合并顺序为基线 → value → add大小写不敏感去重首次出现者优先并会对未知类型做软丢弃soft-drop并输出 warn 日志。注解建模entity-registry/src/main/java/com/linkedin/metadata/models/annotation/EntityAnnotation.java定义了viewUnrestricted字段EntitySpec.java通过isViewUnrestricted()暴露该属性。测试佐证metadata-service/configuration/src/test/java/com/linkedin/metadata/config/ViewAuthorizationConfigurationTest.java断言schemaField、container不出现在 stock value 中且VIEW_UNRESTRICTED_ENTITY_TYPES_ADD默认必须为空。将列schemaField设为受限后的两条路径以默认的schemaField受限为例存在两条不同的生效路径实体页 / Schema 标签页VBAC查看某一列时会先从该列 URN 中编码的父数据集继承View Entity权限urn:li:schemaField:(datasetUrn,fieldPath)若继承失败再回退到对该列 URN 的直接授权。因此能打开数据集的用户就能打开其列即使该列本身没有任何 domain、owner 或 container。搜索结果SBAC仅 Cloud查询时过滤仍只评估索引命中文档上的 facets。列column文档通常不存储父级 domain、container 或 owner 字段因此这些策略条件无法像匹配数据集那样匹配列。Cloud SBAC 下schemaField的限制矩阵策略形态搜索中的数据集搜索中的列schemaFieldDomain / container / resource-owner 过滤通过数据集文档上的 facets 匹配不匹配——列文档缺少这些 facets不存在父级 domain/container/owner 下推TYPE dataset单独或与其他过滤条件 AND匹配被排除——类型子句要求dataset即使兄弟 URN 子句可匹配schemaField 命中也会失败数据集上的 URN equals / starts-with且 type 未设置或包含schemaField匹配匹配——Cloud 会用urn:li:schemaField:(datasetUrn,前缀扩展 URN 过滤因此域范围的「Finance 域数据集上的 View Entity」策略可以正确地把 Finance 数据集从非授权用户的搜索中隐藏同时仍允许授权用户在数据集页浏览其列——但这些列不会作为独立搜索命中出现。若要让列在 SAC 下出现在搜索中应使用 URN 范围的授权不要只限定TYPE dataset、显式的TYPE schemaField策略或保持schemaField不受限若不允许列在搜索中泄露则不推荐此做法。DataHub Core不实现这种 URN 前缀搜索下推其VIEW_AUTHORIZATION_ENABLED仅做实体页面门禁 / 搜索结果后置掩码。基于策略的过滤Policy-Based Filtering搜索结果自动基于以下条件过滤授予View Entity权限的**已启用active**策略。工作原理用户执行一次搜索时DataHub 找出所有授予该用户View Entity权限的已启用策略逐条策略评估其资源过滤器domains、tags 等只有命中至少一条适用策略的实体才会进入搜索结果过滤发生在查询时query time保证所有搜索界面返回一致的结果。该特性由你的 DataHub Cloud 管理员启用。如需为组织开启 Search Access Controls请联系你的管理员。Peer Group 推荐过滤启用 Search Access Controls 后首页的Most Popular最受欢迎推荐也可被过滤以防止信息泄露。Peer Group 的工作原理peer group 设置控制「Most Popular」推荐的计算方式设置行为Peer Group 启用推荐展示与你同组成员正在查看的内容。可以看到同事间的热门资产同时避免窥见其他团队在访问什么Peer Group 禁用推荐仅基于你自己的活动。只会看到你此前查看过的资产这可以防止用户通过「Most Popular」推荐中出现敏感数据而间接推断其存在——即使他们无法直接访问这些数据。对应的底层配置项为authorization.view.recommendations.peerGroupEnabled环境变量VIEW_AUTHORIZATION_RECOMMENDATIONS_PEER_GROUP_ENABLED默认true见 application.yaml。实战场景两个团队三个域本节以「两个团队需要不同访问级别」的组织为例完整演示 Search Access Controls 的搭建过程。业务背景组织希望保证Engineering工程团队只能发现工程相关数据Finance财务团队只能发现财务数据两个团队都能访问共享的公司指标数据。访问矩阵域工程团队财务团队Engineering Data工程数据可查看不可查看Finance Data财务数据不可查看可查看Company Metrics公司指标可查看可查看第 1 步创建域Domains进入Settings Domains创建以下三个域Engineering Data描述包含所有工程数据集、仪表盘和管道将所有工程相关资产分配到该域Finance Data描述包含所有财务数据集和报表将所有财务相关资产分配到该域Company Metrics描述包含所有团队都可访问的共享 KPI 与仪表盘将跨职能资产分配到该域第 2 步创建用户组Groups进入Settings Users Groups Groups创建Engineering Team把所有工程用户添加为成员Finance Team把所有财务用户添加为成员。第 3 步移除默认读访问策略为了保证用户只能看到被显式授权的实体必须停用或删除默认读访问策略进入Settings Permissions Policies找到授予「All Users」以View Entity的默认策略停用或删除这些策略。:::caution 移除默认读访问策略后在创建显式访问策略之前用户将看不到任何搜索结果中的实体。请在执行此变更前规划好你的访问策略。 :::第 4 步创建工程访问策略进入Settings Permissions Policies点击Create PolicyPolicy NameEngineering Team - View AccessPolicy TypeMetadata PolicyPrivileges选择View EntityActors选择Engineering Team组Resources在 Domain 列表中选择Engineering Data和Company Metrics点击Save第 5 步创建财务访问策略再创建一条策略Policy NameFinance Team - View AccessPolicy TypeMetadata PolicyPrivileges选择View EntityActors选择Finance Team组Resources在 Domain 列表中选择Finance Data和Company Metrics点击Save创建完成后可以在策略列表中看到全部已配置的视图访问策略。第 6 步验证配置以各组的用户身份登录验证访问控制是否按预期工作。Alice工程团队登录并搜索时只能发现 Engineering Data 与 Company Metrics 两个域中的实体。David财务团队登录并搜索时只能发现 Finance Data 与 Company Metrics 两个域中的实体。重要注意事项域分配所有实体都应分配到域此方案才能有效工作未分配域的实体不会被基于域的策略匹配考虑为未分配实体创建兜底策略catch-all policy或默认域。平台管理员具有平台管理员权限的用户会绕过Search Access Controls管理员用户无论策略如何都能看到所有实体仅在必要时使用管理员账号。角色Roles所有角色Admin、Editor、Reader都会覆盖基于视图的访问策略被分配了任意角色的用户都能看到所有实体不受基于域的 View Entity 策略限制配置 Search Access Controls 时如果要限制某用户访问请确保其未被分配任何角色。关于角色覆盖视图策略的行为Policies 指南 中亦有明确说明启用 VBAC 时 Admin、Editor、Reader 角色会覆盖基于视图的策略限制。一致的访问控制View Entity 权限同时作用于搜索结果与直接 URL 访问没有权限的用户既无法在搜索中发现实体也无法通过直接链接访问实体无论用户以何种方式尝试查看实体访问控制都是一致的。资源过滤类型策略可按以下维度过滤资源Domain最常用于表达组织边界Tag适合基于数据分类的访问如 PII、Confidential或向特定实体授权。另需注意 Policies 指南 中的性能提示启用视图访问控制后domain 过滤器可能开销较大——DataHub 会对每次授权检查遍历 domain 层级container 过滤器则会顺序遍历容器层级。应优先使用基于 ownership 的策略并在使用 domain 分隔写入方时保持 domain 层级浅平。常见问题FAQ实体没有分配域会怎样未分配域的实体不会命中基于域的策略。这些实体只会对拥有以下策略的用户可见授予全部资源访问权限无资源过滤的策略使用其他过滤类型如 tags且能匹配该实体的策略。如何向特定实体而非域授权使用 tag 标记特定实体。创建一个 tag如 Finance Approved并应用到要授权的实体上然后创建基于 tag 资源过滤的策略。相比 URN 策略这种方式更易维护——通过增删 tag 即可方便地调整授权范围。能否用 tag 替代 domain 做访问控制可以。把资源过滤类型选为Tag即可。当你的访问边界与数据分类对齐而非组织结构时这种方式更合适。用户看不到预期结果时如何排查确认用户属于正确的组检查策略处于启用而非停用状态确认实体被分配到正确的域 / 打上了正确的 tag确认策略包含View Entity权限检查是否存在冲突的 deny 策略记住平台管理员不受策略限制可看到所有实体。Search Access Controls 会影响 GraphQL API 吗会。同样的过滤同样作用于通过 GraphQL API 的程序化访问。用户只会收到其有权限查看的实体。为什么用户没有 View Entity 授权仍能看到列schemaField仓库自带的受控豁免覆盖层不包含schemaField以及document/container。如果用户无需授权仍能打开列请检查是否通过VIEW_UNRESTRICTED_ENTITY_TYPES或_ADD重新加入了schemaField或者用户是否从 schemaField URN 中编码的父数据集继承了View Entity。参见上文 实体类型绕过视图检查。为什么能看到父数据集的用户其列却不显示在搜索结果中实体页面访问从父数据集继承但Cloud 的搜索过滤不继承。Domain、container 和 resource-owner 策略匹配的是搜索文档上的 facets而列文档通常缺少这些 facets。设置TYPE dataset的策略也会排除schemaField命中。只有 URN 范围的数据集授权可以通过 Cloud 专属的 URN 前缀机制匹配到列。参见上文 将列schemaField设为受限后的两条路径。能否创建拒绝deny型策略DataHub 策略是**授权型grant-based**的。要拒绝访问必须移除授权。注意你还需要停用或删除授予「All Users」以View Entity的默认读访问策略见上文第 3 步。移除默认策略并启用 Search Access Controls 后用户在获得显式授权前没有任何访问权限。小结Search Access Controls 把 DataHub 的发现能力从「开箱即用」转变为「按策略授权」启用后搜索、浏览、直接 URL 与 GraphQL API 全部统一受 View Entity 权限约束viewUnrestricted机制registry 基线 VIEW_UNRESTRICTED_ENTITY_TYPES系列环境变量为策略类、平台类等内部实体保留豁免而schemaField等默认受限类型则需特别留意「实体页继承父数据集、搜索不继承」的差异。在生产落地时建议结合 Policies 指南 的 VBAC 策略设计原则先规划好域、标签与角色分配再停用默认读策略最后用不同组的账号逐项验证搜索结果形成完整的「默认拒绝」访问体系。【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 DataHub 搜索访问控制（Search Access Controls）实战指南：用 View Entity 权限实现查询时结果过滤
DataHub 搜索访问控制Search Access Controls实战指南用 View Entity 权限实现查询时结果过滤【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub本指南完整讲解 DataHub 的Search Access Controls搜索访问控制它基于View Entity查看实体权限在查询时过滤搜索结果让用户只能发现其被授权访问的实体实现「默认拒绝」的安全模型。读完本文你将掌握该功能的启用前提与生效边界、viewUnrestricted实体豁免机制的底层原理、schemaField 列级搜索的已知限制以及一套「两团队三域」从建域、建组到策略配置、验证效果的完整落地步骤。功能定位它是 DataHub Cloud 专属特性Search Access Controls 允许组织限制用户能通过搜索结果发现的实体。该特性使用View Entity权限基于访问策略Policies过滤搜索结果确保用户只能看到其被授权访问的元数据。:::note DataHub Core 部署 带查询时过滤query-time filtering的 Search Access Controls 是DataHub Cloud功能。在 OSSDataHub Core上设置VIEW_AUTHORIZATION_ENABLEDtrue只能实现实体页面门禁entity page gating不会在查询时过滤搜索。参见 Policies 指南中的 view-based access control 策略设计。 :::从 策略设计文档 中的对比表格可以更清晰地看到两种部署形态的能力差异部署形态启用方式生效范围DataHub Cloud启用 Search Access ControlsView Entity权限搜索结果在查询时被过滤DataHub CoreGMS 上设置VIEW_AUTHORIZATION_ENABLEDtrueView Entity Page权限实体页面门禁与可选的搜索结果后置掩码——不是Elasticsearch 查询下推核心概念View Entity 权限View Entity权限控制用户能否发现并访问某个实体。启用 Search Access Controls 后用户在搜索结果中只会看到被授予查看权限的实体用户无法通过直接 URL 访问受限实体访问控制一致地作用于搜索search、浏览browse与直接访问direct access三种途径。这种统一策略保证了无论用户以何种方式尝试发现或查看实体访问控制都会被一致地执行。默认行为未启用 Search Access Controls 时所有用户都能在搜索结果中看到所有实体不基于策略做任何过滤。启用之后搜索结果基于适用于该用户的策略进行过滤只有命中至少一条包含View Entity权限的策略的实体才会被返回由此形成「默认拒绝default deny」模型——必须显式授予权限才能看到任何实体。实体类型绕过视图检查Entity types that bypass view checks启用 Search Access Controls 后仍有部分实体类型会完全绕过视图授权无需 View Entity 授权即可出现在搜索结果中。其机制分两层基线baseline在entity-registry.yml中通过viewUnrestricted: true声明「精简基线」覆盖overlay可选的VIEW_UNRESTRICTED_ENTITY_TYPES仓库自带的 CSV整体替换该 CSV 时覆盖的是 application 覆盖层而不是 registry 基线外加VIEW_UNRESTRICTED_ENTITY_TYPES_ADD/VIEW_UNRESTRICTED_ENTITY_TYPES_REMOVE两个增删操作。增删覆盖会改变最终生效的默认列表。所有其他类型的实体默认受限。关键点最终生效的默认列表 原不受限 CSV减去已在entity-registry.yml中标记的类型。默认列表不包含document、schemaField、container——这些类型在视图授权开启时默认受限container已不再于 registry 中被标记为viewUnrestricted。除非你确实想绕过视图检查否则不要通过VIEW_UNRESTRICTED_ENTITY_TYPES_ADD把它们加回去。这些是 GMS 环境变量参见 Environment Variables 文档。同一份列表在 DataHub Core 部署中同样作用于VIEW_AUTHORIZATION_ENABLEDtrue时的核心视图授权——但那只是实体页面门禁 / 搜索结果后置掩码查询时搜索过滤仍是 DataHub Cloud 专属。相关破坏性变更细节见 updating DataHub。仓库中的配置与实现证据以上机制在当前仓库中有完整实现可对照配置入口metadata-service/configuration/src/main/resources/application.yaml的authorization.view配置块约 L102-L130authorization.view.enabled默认${VIEW_AUTHORIZATION_ENABLED:false}即默认关闭authorization.view.unrestrictedEntityTypes.value默认值即仓库内置 CSV——dataHubPolicy,dataProcess,dataHubIngestionSource,dataHubSecret,service,dataHubExecutionRequest,assertion,mlModelDeployment,dataHubAccessToken,test,inviteToken,versionSet,incident,erModelRelationship,application,semanticModel,metric,businessAttribute,dataContract,dataHubAction,dataHubConnection,platformResource,aiAgent,api,repository,agentSkilladd/remove分别对应VIEW_UNRESTRICTED_ENTITY_TYPES_ADD、VIEW_UNRESTRICTED_ENTITY_TYPES_REMOVE默认均为空配置注释明确写出 registry 基线覆盖的类型identity 类如corpuser/corpGroup、platform 类如dataPlatform、metadata 模型类如ownershipType/structuredProperty/form/role等并强调document/schemaField/container刻意不出现在默认列表中。registry 基线声明metadata-models/src/main/resources/entity-registry.yml中大量实体声明了viewUnrestricted: true例如第 1-15 行的dataPlatform与role。解析与合并逻辑metadata-io/src/main/java/com/linkedin/metadata/search/utils/EntityTypeUtils.java的resolve(ViewUnrestrictedEntityTypes, EntityRegistry)方法实现了「registry 基线 → value 覆盖层 → add/remove 增删」的合并顺序为基线 → value → add大小写不敏感去重首次出现者优先并会对未知类型做软丢弃soft-drop并输出 warn 日志。注解建模entity-registry/src/main/java/com/linkedin/metadata/models/annotation/EntityAnnotation.java定义了viewUnrestricted字段EntitySpec.java通过isViewUnrestricted()暴露该属性。测试佐证metadata-service/configuration/src/test/java/com/linkedin/metadata/config/ViewAuthorizationConfigurationTest.java断言schemaField、container不出现在 stock value 中且VIEW_UNRESTRICTED_ENTITY_TYPES_ADD默认必须为空。将列schemaField设为受限后的两条路径以默认的schemaField受限为例存在两条不同的生效路径实体页 / Schema 标签页VBAC查看某一列时会先从该列 URN 中编码的父数据集继承View Entity权限urn:li:schemaField:(datasetUrn,fieldPath)若继承失败再回退到对该列 URN 的直接授权。因此能打开数据集的用户就能打开其列即使该列本身没有任何 domain、owner 或 container。搜索结果SBAC仅 Cloud查询时过滤仍只评估索引命中文档上的 facets。列column文档通常不存储父级 domain、container 或 owner 字段因此这些策略条件无法像匹配数据集那样匹配列。Cloud SBAC 下schemaField的限制矩阵策略形态搜索中的数据集搜索中的列schemaFieldDomain / container / resource-owner 过滤通过数据集文档上的 facets 匹配不匹配——列文档缺少这些 facets不存在父级 domain/container/owner 下推TYPE dataset单独或与其他过滤条件 AND匹配被排除——类型子句要求dataset即使兄弟 URN 子句可匹配schemaField 命中也会失败数据集上的 URN equals / starts-with且 type 未设置或包含schemaField匹配匹配——Cloud 会用urn:li:schemaField:(datasetUrn,前缀扩展 URN 过滤因此域范围的「Finance 域数据集上的 View Entity」策略可以正确地把 Finance 数据集从非授权用户的搜索中隐藏同时仍允许授权用户在数据集页浏览其列——但这些列不会作为独立搜索命中出现。若要让列在 SAC 下出现在搜索中应使用 URN 范围的授权不要只限定TYPE dataset、显式的TYPE schemaField策略或保持schemaField不受限若不允许列在搜索中泄露则不推荐此做法。DataHub Core不实现这种 URN 前缀搜索下推其VIEW_AUTHORIZATION_ENABLED仅做实体页面门禁 / 搜索结果后置掩码。基于策略的过滤Policy-Based Filtering搜索结果自动基于以下条件过滤授予View Entity权限的**已启用active**策略。工作原理用户执行一次搜索时DataHub 找出所有授予该用户View Entity权限的已启用策略逐条策略评估其资源过滤器domains、tags 等只有命中至少一条适用策略的实体才会进入搜索结果过滤发生在查询时query time保证所有搜索界面返回一致的结果。该特性由你的 DataHub Cloud 管理员启用。如需为组织开启 Search Access Controls请联系你的管理员。Peer Group 推荐过滤启用 Search Access Controls 后首页的Most Popular最受欢迎推荐也可被过滤以防止信息泄露。Peer Group 的工作原理peer group 设置控制「Most Popular」推荐的计算方式设置行为Peer Group 启用推荐展示与你同组成员正在查看的内容。可以看到同事间的热门资产同时避免窥见其他团队在访问什么Peer Group 禁用推荐仅基于你自己的活动。只会看到你此前查看过的资产这可以防止用户通过「Most Popular」推荐中出现敏感数据而间接推断其存在——即使他们无法直接访问这些数据。对应的底层配置项为authorization.view.recommendations.peerGroupEnabled环境变量VIEW_AUTHORIZATION_RECOMMENDATIONS_PEER_GROUP_ENABLED默认true见 application.yaml。实战场景两个团队三个域本节以「两个团队需要不同访问级别」的组织为例完整演示 Search Access Controls 的搭建过程。业务背景组织希望保证Engineering工程团队只能发现工程相关数据Finance财务团队只能发现财务数据两个团队都能访问共享的公司指标数据。访问矩阵域工程团队财务团队Engineering Data工程数据可查看不可查看Finance Data财务数据不可查看可查看Company Metrics公司指标可查看可查看第 1 步创建域Domains进入Settings Domains创建以下三个域Engineering Data描述包含所有工程数据集、仪表盘和管道将所有工程相关资产分配到该域Finance Data描述包含所有财务数据集和报表将所有财务相关资产分配到该域Company Metrics描述包含所有团队都可访问的共享 KPI 与仪表盘将跨职能资产分配到该域第 2 步创建用户组Groups进入Settings Users Groups Groups创建Engineering Team把所有工程用户添加为成员Finance Team把所有财务用户添加为成员。第 3 步移除默认读访问策略为了保证用户只能看到被显式授权的实体必须停用或删除默认读访问策略进入Settings Permissions Policies找到授予「All Users」以View Entity的默认策略停用或删除这些策略。:::caution 移除默认读访问策略后在创建显式访问策略之前用户将看不到任何搜索结果中的实体。请在执行此变更前规划好你的访问策略。 :::第 4 步创建工程访问策略进入Settings Permissions Policies点击Create PolicyPolicy NameEngineering Team - View AccessPolicy TypeMetadata PolicyPrivileges选择View EntityActors选择Engineering Team组Resources在 Domain 列表中选择Engineering Data和Company Metrics点击Save第 5 步创建财务访问策略再创建一条策略Policy NameFinance Team - View AccessPolicy TypeMetadata PolicyPrivileges选择View EntityActors选择Finance Team组Resources在 Domain 列表中选择Finance Data和Company Metrics点击Save创建完成后可以在策略列表中看到全部已配置的视图访问策略。第 6 步验证配置以各组的用户身份登录验证访问控制是否按预期工作。Alice工程团队登录并搜索时只能发现 Engineering Data 与 Company Metrics 两个域中的实体。David财务团队登录并搜索时只能发现 Finance Data 与 Company Metrics 两个域中的实体。重要注意事项域分配所有实体都应分配到域此方案才能有效工作未分配域的实体不会被基于域的策略匹配考虑为未分配实体创建兜底策略catch-all policy或默认域。平台管理员具有平台管理员权限的用户会绕过Search Access Controls管理员用户无论策略如何都能看到所有实体仅在必要时使用管理员账号。角色Roles所有角色Admin、Editor、Reader都会覆盖基于视图的访问策略被分配了任意角色的用户都能看到所有实体不受基于域的 View Entity 策略限制配置 Search Access Controls 时如果要限制某用户访问请确保其未被分配任何角色。关于角色覆盖视图策略的行为Policies 指南 中亦有明确说明启用 VBAC 时 Admin、Editor、Reader 角色会覆盖基于视图的策略限制。一致的访问控制View Entity 权限同时作用于搜索结果与直接 URL 访问没有权限的用户既无法在搜索中发现实体也无法通过直接链接访问实体无论用户以何种方式尝试查看实体访问控制都是一致的。资源过滤类型策略可按以下维度过滤资源Domain最常用于表达组织边界Tag适合基于数据分类的访问如 PII、Confidential或向特定实体授权。另需注意 Policies 指南 中的性能提示启用视图访问控制后domain 过滤器可能开销较大——DataHub 会对每次授权检查遍历 domain 层级container 过滤器则会顺序遍历容器层级。应优先使用基于 ownership 的策略并在使用 domain 分隔写入方时保持 domain 层级浅平。常见问题FAQ实体没有分配域会怎样未分配域的实体不会命中基于域的策略。这些实体只会对拥有以下策略的用户可见授予全部资源访问权限无资源过滤的策略使用其他过滤类型如 tags且能匹配该实体的策略。如何向特定实体而非域授权使用 tag 标记特定实体。创建一个 tag如 Finance Approved并应用到要授权的实体上然后创建基于 tag 资源过滤的策略。相比 URN 策略这种方式更易维护——通过增删 tag 即可方便地调整授权范围。能否用 tag 替代 domain 做访问控制可以。把资源过滤类型选为Tag即可。当你的访问边界与数据分类对齐而非组织结构时这种方式更合适。用户看不到预期结果时如何排查确认用户属于正确的组检查策略处于启用而非停用状态确认实体被分配到正确的域 / 打上了正确的 tag确认策略包含View Entity权限检查是否存在冲突的 deny 策略记住平台管理员不受策略限制可看到所有实体。Search Access Controls 会影响 GraphQL API 吗会。同样的过滤同样作用于通过 GraphQL API 的程序化访问。用户只会收到其有权限查看的实体。为什么用户没有 View Entity 授权仍能看到列schemaField仓库自带的受控豁免覆盖层不包含schemaField以及document/container。如果用户无需授权仍能打开列请检查是否通过VIEW_UNRESTRICTED_ENTITY_TYPES或_ADD重新加入了schemaField或者用户是否从 schemaField URN 中编码的父数据集继承了View Entity。参见上文 实体类型绕过视图检查。为什么能看到父数据集的用户其列却不显示在搜索结果中实体页面访问从父数据集继承但Cloud 的搜索过滤不继承。Domain、container 和 resource-owner 策略匹配的是搜索文档上的 facets而列文档通常缺少这些 facets。设置TYPE dataset的策略也会排除schemaField命中。只有 URN 范围的数据集授权可以通过 Cloud 专属的 URN 前缀机制匹配到列。参见上文 将列schemaField设为受限后的两条路径。能否创建拒绝deny型策略DataHub 策略是**授权型grant-based**的。要拒绝访问必须移除授权。注意你还需要停用或删除授予「All Users」以View Entity的默认读访问策略见上文第 3 步。移除默认策略并启用 Search Access Controls 后用户在获得显式授权前没有任何访问权限。小结Search Access Controls 把 DataHub 的发现能力从「开箱即用」转变为「按策略授权」启用后搜索、浏览、直接 URL 与 GraphQL API 全部统一受 View Entity 权限约束viewUnrestricted机制registry 基线 VIEW_UNRESTRICTED_ENTITY_TYPES系列环境变量为策略类、平台类等内部实体保留豁免而schemaField等默认受限类型则需特别留意「实体页继承父数据集、搜索不继承」的差异。在生产落地时建议结合 Policies 指南 的 VBAC 策略设计原则先规划好域、标签与角色分配再停用默认读策略最后用不同组的账号逐项验证搜索结果形成完整的「默认拒绝」访问体系。【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考