DataHub Access Roles将外部 IAM 角色纳入数据目录构建统一的数据访问管理视图【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahubDataHub 的 Access RolesAccess Management特性允许你把 Snowflake、BigQuery 等外部系统中的角色Role连同你的数据资产一起摄入 DataHub让用户在查看某个表或数据集时能直接看到哪些角色已经拥有该资产的访问权限并通过角色附带的请求链接跳转到外部平台申请相应权限。本文基于 DataHub 仓库中的官方特性文档 access-roles.md完整讲解该特性的启用方式、元数据模型role实体与accessaspect 的 PDL 定义、以及通过 CLI 和 Python API 写入角色元数据的三步完整操作流程。需要说明的是该特性目前处于 Private Beta 阶段。特性定位与 Data Access Workflows 的区别Access Roles 解决的核心问题是在数据目录中呈现已有的访问控制关系。它与 DataHub 的 Data Access Workflows 是两个互补但不同的机制Data Access Workflows在 DataHub 内部创建申请-审批工作流用于请求表、仪表盘等资产的访问权限Access Roles本特性把外部系统里已经存在的角色定义如 Snowflake 的 Reader 角色同步到 DataHub让用户理解这个资产上已经有哪些角色具备权限并重定向到外部平台去申请加入对应角色。这一能力为数据消费者带来三点实际价值Discover available access—— 跨不同数据平台发现自己已被授予了哪些角色Request appropriate access—— 快速识别并申请加入满足所需权限的角色Simplify governance—— 把分散在各平台中的角色信息集中到 DataHub简化访问管理流程。启用 Access Management 特性DataHub Core通过环境变量开启在 DataHub Core 部署中Access Management 特性默认禁用。启用方式为在datahub-gms服务容器上设置环境变量SHOW_ACCESS_MANAGEMENTtrue例如在你的docker/datahub-gms/docker.env中配置SHOW_ACCESS_MANAGEMENTtrue这个开关的底层配置链路可以在 GMS 的配置文件中确认application.yaml 中定义了showAccessManagement: ${SHOW_ACCESS_MANAGEMENT:false} # Whether we should show AccessManagement tab in the datahub UI.即该开关默认值为false其作用正是控制 DataHub UI 中是否渲染 Access Management 标签页。配置后数据集详情页应出现名为Access Management的新 Tab如果 Tab 没有显示优先检查 GMS 侧环境变量是否生效。DataHub Cloud使用 DataHub Cloud 时只需联系你的 CustomerSuccess 代表即可在环境中启用该特性无需自己做任何配置变更。数据模型role 实体与 access aspectAccess Management 在 DataHub 元数据模型中引入了一个新的实体Role。一个 Role 由以下部分组成唯一的实体标识URN格式为urn:li:role:id角色的属性name、description、type、request URL已被授予该角色的用户列表。角色随后通过一个名为access的新 aspect 与数据集Dataset关联起来。当前版本中仅 Dataset 实体支持 Access Management。PDL 定义佐证仓库中的 Pegasus 数据定义可以印证上述模型RoleKey.pdlrole 实体的 key aspect核心字段为id: string即 URN 中urn:li:role:之后的部分RoleProperties.pdl角色属性 aspect字段说明如下字段类型说明namestring必填外部系统IAM中角色的显示名带Searchable注解支持自动补全别名_entityNamedescriptionoptional string角色描述typestring必填角色类型取值为READ、ADMIN、WRITErequestUrloptional string跳转到外部访问管理平台的链接createdoptional AuditStamp创建审计信息RoleUser.pdl / RoleGroup.pdl分别表示被授予角色的 corp user 与 corp groupRelationship注解为Has即角色到用户/组的关系边RoleAssociation.pdl已关联角色的 URNRelationship为AssociatedWith指向role实体且带Searchable注解filterNameOverride为 Role——这意味着数据集的 access 关联会进入搜索过滤体系从源码结构看角色信息可以被用作搜索过滤条件Access.pdl挂在数据集上的accessaspect 定义内容为角色 URN 列表。重要不要混淆 role 与 datahubrolerole实体指外部源系统如 Snowflake、BigQuery中存在的外部角色定义datahubrole用于管理 DataHub 内部的权限如 admin 角色可以接受提案的元数据变更。两者的用途完全不同摄入外部 IAM 角色时应始终使用urn:li:role:...形式的 URN。通过 CLI / Python API 管理访问元数据完整流程分三步创建外部角色 → 可选把用户分配到角色 → 把角色分配到数据集。以下操作均可通过datahub putCLI 命令或 Python Emitter API 完成。第一步创建外部角色roleProperties aspectCLI 方式datahub put --urn urn:li:role:reader --aspect roleProperties -d - -EOF { name: Snowflake Reader Role, description: Description for Snowflake Reader Role, type: READ, requestUrl: http://custom-url-for-redirection.com } EOFPython 方式import datahub.emitter.mce_builder as builder from datahub.emitter.rest_emitter import DatahubRestEmitter from datahub.emitter.mcp import MetadataChangeProposalWrapper from datahub.metadata.schema_classes import RolePropertiesClass, ChangeTypeClass # Create a role properties aspect role_properties RolePropertiesClass( nameSnowflake Reader Role, descriptionDescription for Snowflake Reader Role, typeREAD, requestUrlhttp://custom-url-for-redirection.com ) # Create a metadata change proposal mcp MetadataChangeProposalWrapper( changeTypeChangeTypeClass.UPSERT, entityUrnurn:li:role:reader, aspectNameroleProperties, aspectrole_properties ) # Emit the metadata emitter DatahubRestEmitter(gms_serverhttp://localhost:8080) emitter.emit(mcp)对照 RoleProperties.pdl 的定义name和type为必填字段type的约定取值为READ、ADMIN、WRITErequestUrl决定 UI 上点击角色后的跳转目标应指向你实际的权限申请入口。第二步可选把用户分配到角色actors aspect如果你想同时呈现谁已经被授予了这个角色可以对 role 实体写入actorsaspectCLI 方式datahub put --urn urn:li:role:reader --aspect actors -d - -EOF { users: [ {user: urn:li:corpuser:datahubuser} ] } EOFPython 方式from datahub.metadata.schema_classes import ActorsClass, ActorClass # Create an actors aspect actors ActorsClass( users[ ActorClass(userurn:li:corpuser:datahubuser) ] ) # Create a metadata change proposal mcp MetadataChangeProposalWrapper( changeTypeChangeTypeClass.UPSERT, entityUrnurn:li:role:reader, aspectNameactors, aspectactors ) # Emit the metadata emitter.emit(mcp)actors写入后在 role 实体与urn:li:corpuser:...之间会建立Has关系边见 RoleUser.pdl 的Relationship注解DataHub 即可回答某用户拥有哪些角色这类查询。第三步把角色分配到数据集access aspect最后一步是在目标数据集上写入accessaspect把角色 URN 列表关联到数据集CLI 方式以 Hive 数据集为例datahub put --urn urn:li:dataset:(urn:li:dataPlatform:hive,fct_users_created,PROD) --aspect access -d - -EOF { roles: [ {urn: urn:li:role:reader}, {urn: urn:li:role:writer} ] } EOFPython 方式from datahub.metadata.schema_classes import AccessClass, RoleAssociationClass dataset_urn urn:li:dataset:(urn:li:dataPlatform:hive,fct_users_created,PROD) # Create an access aspect with multiple roles access_aspect AccessClass( roles[ RoleAssociationClass(urnurn:li:role:reader), RoleAssociationClass(urnurn:li:role:writer) ] ) # Create a metadata change proposal mcp MetadataChangeProposalWrapper( changeTypeChangeTypeClass.UPSERT, entityUrndataset_urn, aspectNameaccess, aspectaccess_aspect ) # Emit the metadata emitter.emit(mcp)由于RoleAssociation携带Relationship AssociatedWith注解写入后数据集与角色之间会形成图关系配合 UI 的 Access Management Tab即可在数据集页面上看到已关联的角色及其requestUrl跳转入口。典型使用场景将外部角色集成进 DataHub 后以下场景都能直接受益Unified Access View统一访问视图数据工程师可以在单一界面中查看多个平台上所有能访问敏感数据的用户Self-Service Access Requests自助访问申请分析师可以发现访问特定数据集需要哪些角色并直接从 DataHub 跳转到对应入口申请Access Auditing访问审计合规团队可以审查谁、通过哪个角色、访问了哪些数据集Onboarding Acceleration加速入职新成员可以快速发现自己岗位所需的访问权限清单。后续演进方向官方文档同时列出了 Access Management 的规划方向可以作为选型时的预期边界参考除角色roles之外进一步建模外部策略policies自动从 BigQuery、Snowflake 等数据源中提取角色/策略而不是完全依赖手工摄入将支持范围从 Dataset 扩展到更多实体类型支持带审批流程的高级访问请求工作流。小结Access Roles 是 DataHub 把访问控制纳入数据目录元数据模型的一步以role实体承载外部角色定义roleKey/roleProperties/actors三类 aspect以数据集上的accessaspect 建立资产 ↔ 角色关联再通过 GMS 的SHOW_ACCESS_MANAGEMENT开关在 UI 中呈现。在 Private Beta 阶段它当前仅支持 Dataset 实体角色数据需通过 CLI 或 Python Emitter 手工或脚本化摄入——但正是这种目录内可见角色、一键跳转申请的机制显著降低了跨平台数据访问沟通的成本。【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 DataHub Access Roles：将外部 IAM 角色纳入数据目录，构建统一的数据访问管理视图
DataHub Access Roles将外部 IAM 角色纳入数据目录构建统一的数据访问管理视图【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahubDataHub 的 Access RolesAccess Management特性允许你把 Snowflake、BigQuery 等外部系统中的角色Role连同你的数据资产一起摄入 DataHub让用户在查看某个表或数据集时能直接看到哪些角色已经拥有该资产的访问权限并通过角色附带的请求链接跳转到外部平台申请相应权限。本文基于 DataHub 仓库中的官方特性文档 access-roles.md完整讲解该特性的启用方式、元数据模型role实体与accessaspect 的 PDL 定义、以及通过 CLI 和 Python API 写入角色元数据的三步完整操作流程。需要说明的是该特性目前处于 Private Beta 阶段。特性定位与 Data Access Workflows 的区别Access Roles 解决的核心问题是在数据目录中呈现已有的访问控制关系。它与 DataHub 的 Data Access Workflows 是两个互补但不同的机制Data Access Workflows在 DataHub 内部创建申请-审批工作流用于请求表、仪表盘等资产的访问权限Access Roles本特性把外部系统里已经存在的角色定义如 Snowflake 的 Reader 角色同步到 DataHub让用户理解这个资产上已经有哪些角色具备权限并重定向到外部平台去申请加入对应角色。这一能力为数据消费者带来三点实际价值Discover available access—— 跨不同数据平台发现自己已被授予了哪些角色Request appropriate access—— 快速识别并申请加入满足所需权限的角色Simplify governance—— 把分散在各平台中的角色信息集中到 DataHub简化访问管理流程。启用 Access Management 特性DataHub Core通过环境变量开启在 DataHub Core 部署中Access Management 特性默认禁用。启用方式为在datahub-gms服务容器上设置环境变量SHOW_ACCESS_MANAGEMENTtrue例如在你的docker/datahub-gms/docker.env中配置SHOW_ACCESS_MANAGEMENTtrue这个开关的底层配置链路可以在 GMS 的配置文件中确认application.yaml 中定义了showAccessManagement: ${SHOW_ACCESS_MANAGEMENT:false} # Whether we should show AccessManagement tab in the datahub UI.即该开关默认值为false其作用正是控制 DataHub UI 中是否渲染 Access Management 标签页。配置后数据集详情页应出现名为Access Management的新 Tab如果 Tab 没有显示优先检查 GMS 侧环境变量是否生效。DataHub Cloud使用 DataHub Cloud 时只需联系你的 CustomerSuccess 代表即可在环境中启用该特性无需自己做任何配置变更。数据模型role 实体与 access aspectAccess Management 在 DataHub 元数据模型中引入了一个新的实体Role。一个 Role 由以下部分组成唯一的实体标识URN格式为urn:li:role:id角色的属性name、description、type、request URL已被授予该角色的用户列表。角色随后通过一个名为access的新 aspect 与数据集Dataset关联起来。当前版本中仅 Dataset 实体支持 Access Management。PDL 定义佐证仓库中的 Pegasus 数据定义可以印证上述模型RoleKey.pdlrole 实体的 key aspect核心字段为id: string即 URN 中urn:li:role:之后的部分RoleProperties.pdl角色属性 aspect字段说明如下字段类型说明namestring必填外部系统IAM中角色的显示名带Searchable注解支持自动补全别名_entityNamedescriptionoptional string角色描述typestring必填角色类型取值为READ、ADMIN、WRITErequestUrloptional string跳转到外部访问管理平台的链接createdoptional AuditStamp创建审计信息RoleUser.pdl / RoleGroup.pdl分别表示被授予角色的 corp user 与 corp groupRelationship注解为Has即角色到用户/组的关系边RoleAssociation.pdl已关联角色的 URNRelationship为AssociatedWith指向role实体且带Searchable注解filterNameOverride为 Role——这意味着数据集的 access 关联会进入搜索过滤体系从源码结构看角色信息可以被用作搜索过滤条件Access.pdl挂在数据集上的accessaspect 定义内容为角色 URN 列表。重要不要混淆 role 与 datahubrolerole实体指外部源系统如 Snowflake、BigQuery中存在的外部角色定义datahubrole用于管理 DataHub 内部的权限如 admin 角色可以接受提案的元数据变更。两者的用途完全不同摄入外部 IAM 角色时应始终使用urn:li:role:...形式的 URN。通过 CLI / Python API 管理访问元数据完整流程分三步创建外部角色 → 可选把用户分配到角色 → 把角色分配到数据集。以下操作均可通过datahub putCLI 命令或 Python Emitter API 完成。第一步创建外部角色roleProperties aspectCLI 方式datahub put --urn urn:li:role:reader --aspect roleProperties -d - -EOF { name: Snowflake Reader Role, description: Description for Snowflake Reader Role, type: READ, requestUrl: http://custom-url-for-redirection.com } EOFPython 方式import datahub.emitter.mce_builder as builder from datahub.emitter.rest_emitter import DatahubRestEmitter from datahub.emitter.mcp import MetadataChangeProposalWrapper from datahub.metadata.schema_classes import RolePropertiesClass, ChangeTypeClass # Create a role properties aspect role_properties RolePropertiesClass( nameSnowflake Reader Role, descriptionDescription for Snowflake Reader Role, typeREAD, requestUrlhttp://custom-url-for-redirection.com ) # Create a metadata change proposal mcp MetadataChangeProposalWrapper( changeTypeChangeTypeClass.UPSERT, entityUrnurn:li:role:reader, aspectNameroleProperties, aspectrole_properties ) # Emit the metadata emitter DatahubRestEmitter(gms_serverhttp://localhost:8080) emitter.emit(mcp)对照 RoleProperties.pdl 的定义name和type为必填字段type的约定取值为READ、ADMIN、WRITErequestUrl决定 UI 上点击角色后的跳转目标应指向你实际的权限申请入口。第二步可选把用户分配到角色actors aspect如果你想同时呈现谁已经被授予了这个角色可以对 role 实体写入actorsaspectCLI 方式datahub put --urn urn:li:role:reader --aspect actors -d - -EOF { users: [ {user: urn:li:corpuser:datahubuser} ] } EOFPython 方式from datahub.metadata.schema_classes import ActorsClass, ActorClass # Create an actors aspect actors ActorsClass( users[ ActorClass(userurn:li:corpuser:datahubuser) ] ) # Create a metadata change proposal mcp MetadataChangeProposalWrapper( changeTypeChangeTypeClass.UPSERT, entityUrnurn:li:role:reader, aspectNameactors, aspectactors ) # Emit the metadata emitter.emit(mcp)actors写入后在 role 实体与urn:li:corpuser:...之间会建立Has关系边见 RoleUser.pdl 的Relationship注解DataHub 即可回答某用户拥有哪些角色这类查询。第三步把角色分配到数据集access aspect最后一步是在目标数据集上写入accessaspect把角色 URN 列表关联到数据集CLI 方式以 Hive 数据集为例datahub put --urn urn:li:dataset:(urn:li:dataPlatform:hive,fct_users_created,PROD) --aspect access -d - -EOF { roles: [ {urn: urn:li:role:reader}, {urn: urn:li:role:writer} ] } EOFPython 方式from datahub.metadata.schema_classes import AccessClass, RoleAssociationClass dataset_urn urn:li:dataset:(urn:li:dataPlatform:hive,fct_users_created,PROD) # Create an access aspect with multiple roles access_aspect AccessClass( roles[ RoleAssociationClass(urnurn:li:role:reader), RoleAssociationClass(urnurn:li:role:writer) ] ) # Create a metadata change proposal mcp MetadataChangeProposalWrapper( changeTypeChangeTypeClass.UPSERT, entityUrndataset_urn, aspectNameaccess, aspectaccess_aspect ) # Emit the metadata emitter.emit(mcp)由于RoleAssociation携带Relationship AssociatedWith注解写入后数据集与角色之间会形成图关系配合 UI 的 Access Management Tab即可在数据集页面上看到已关联的角色及其requestUrl跳转入口。典型使用场景将外部角色集成进 DataHub 后以下场景都能直接受益Unified Access View统一访问视图数据工程师可以在单一界面中查看多个平台上所有能访问敏感数据的用户Self-Service Access Requests自助访问申请分析师可以发现访问特定数据集需要哪些角色并直接从 DataHub 跳转到对应入口申请Access Auditing访问审计合规团队可以审查谁、通过哪个角色、访问了哪些数据集Onboarding Acceleration加速入职新成员可以快速发现自己岗位所需的访问权限清单。后续演进方向官方文档同时列出了 Access Management 的规划方向可以作为选型时的预期边界参考除角色roles之外进一步建模外部策略policies自动从 BigQuery、Snowflake 等数据源中提取角色/策略而不是完全依赖手工摄入将支持范围从 Dataset 扩展到更多实体类型支持带审批流程的高级访问请求工作流。小结Access Roles 是 DataHub 把访问控制纳入数据目录元数据模型的一步以role实体承载外部角色定义roleKey/roleProperties/actors三类 aspect以数据集上的accessaspect 建立资产 ↔ 角色关联再通过 GMS 的SHOW_ACCESS_MANAGEMENT开关在 UI 中呈现。在 Private Beta 阶段它当前仅支持 Dataset 实体角色数据需通过 CLI 或 Python Emitter 手工或脚本化摄入——但正是这种目录内可见角色、一键跳转申请的机制显著降低了跨平台数据访问沟通的成本。【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考