背景信息
阿里云数据湖构建产品（DLF）提供的统一元数据服务，通过完善各种引擎/表格式生态解决了数据湖场景下多引擎面临的数据孤岛和元数据一致性问题，实现了开源大数据引擎及数据湖格式元数据的统一视图，避免了各引擎访问湖上数据其中额外的ETL成本并降低了业务处理链路的延时。但同时另一个问题随之产生即不同的引擎可能有不同的权限模型和用户模型，这导致在不同的引擎上用户和权限无法真正做到互通，如果能够在统一元数据的基础上实现集中式的权限校验，一次权限配置多引擎生效，实现引擎级的权限互通，将极大的提高湖上数据访问的安全性，同时将降低权限管理的复杂性。
实现数据湖统一权限服务方案的要点
因为不同的引擎/表格式在权限方案上/用户模型上存在着差异，例如在用户模型上EMR Hive/Spark 等开源引擎的用户模型可能是 LDAP，但阿里云的其他产品如MaxCompute、Holo 等是阿里云账号/RAM体系，又比如在权限方案上 EMR Hive/Spark/Presto 等或没有自己的安全体系或借助其他平台实现、特别是一些开源体系的表格式 Hudi/iceberg/delta 等目前完全没有权限控制，而在 Maxcompute/Holo 则有自己的一套权限控制体系，即使开源引擎都能够进行权限控制，但权限的数据、模型和权限校验的行为也根本不可能做到一致，所以在统一的元数据视图的基础上，实现统一的权限服务，需要解决四个重要问题
- 不同引擎的用户体系互通问题
- 实现不同引擎的不同的用户体系能够进行互转
- 不同引擎的权限体系互通问题
- 各引擎和格式使用同一套权限校验体系
- 通过元数据 API 访问/引擎访问，鉴权一致性的问题
- 元数据 API 访问也要使用同样的鉴权体系
- 保持不同引擎能够在现有使用方式上
- 在解决上述两个问题的基础上，能够保持现有用户使用方式、产生的元数据不变
数据湖构建之统一权限服务方案介绍
数据湖构建统一权限服务方案依托于数据湖统一元数据，是整个数据湖构建基础服务的一部分。整体方案一方面通过将不同引擎的用户体系映射至同一套用户体系来解决用户识别问题，另一方面通过将数据湖统一权限校验机制与开源体系的 EMR
hive/spark/Presto/Databricks 等引擎、数据湖格式 Hudi/Delta 等以及与 MaxCompute/Holo（进行中）等引擎集成来解决不同引擎权限数据一致性和互通问题，从而开源引擎访问湖上数据时有了统一的元数据视图及权限校验机制。
- 开源引擎/数据湖格式代理鉴权机制
数据湖构建产品是采用类 Ranger Pugin 方案来支持引擎侧鉴权，其方式首先是通过将引擎访问的账号在RAM平台授予 AliyunDLFFullAccess 权限同时将引擎账号添加至 DLF 互信权限名单中（互信权限可通过 Setting API 添加），实现引擎与 DLF 元数据产品的互信，这样当各引擎接受到用户的请求时，这些 Plugin 将拦截该请求并可在引擎侧发起该用户的代理鉴权调用，同时在引擎侧将进行用户模型转换，例如在数据湖构建平台上使用阿里云账号/Ram子账号机制，在引擎侧将 LDAP 用户与云账号进行映射（可采用 LDAP 账号与 RAM 账号同名映射方式简化），鉴权请求在服务端鉴权之后，引擎将鉴权结果返回给用户，此种模式下用户需要具备元数据资源的访问权限即可，权限获取可以通过数据湖构建产品-数据权限页面进行授权获取。
引擎侧整体鉴权流程如下：
- DLF 元数据访问鉴权机制
对于直接访问 DLF 元数据的用户将采用双层鉴权模型，亦即用户需要同时具备 DLF 元数据 API 访问权限（在 RAM 上配置）及元数据资源访问权限。前者需要在 Ram平台进行授权（如下图所示），后者跟引擎代理鉴权模式相同需要通过数据湖构建产品-数据权限页面进行授权获取。
在 Ram 访问控制平台上可选择用户添加权限，如果用户只读元数据可以授予 AliyunDLFReadOnlyAccess 权限。
元数据访问整体鉴权流程如下：
数据湖构建之统一权限服务实践
- 前提条件
- 已开通数据湖构建产品，目前统一权限服务已在所有数据湖构建产品所在region上线。
- 已开通EMR 3.40/5.60及以上版本的集群，如已有其他低版本的EMR请提交工单联系阿里云工程师进行咨询解决。
- 已开启数据湖权限服务端鉴权，可通过如下方式开通
- 需提交工单联系阿里云工程师进行咨询解决
- 通过Settings API（调用 Settings API 需要 DLF Ram Api "dlf:UpdateCatalogSettings"及 DLF admin 角色的权限）
- 未来页面将开放 Settings 配置给用户自行配置
具体内容及操作步骤
- 采用阿里云主账号对阿里云Ram子账号(也可对Ram角色)进行admin/super_administrator 角色授权，以进行分权管理。
- 对其他业务阿里云 Ram 子账（Ram角色）在数据湖构建平台集中实施 database及 table 权限的管理
- 对其他业务阿里云 Ram 子账（Ram 角色）通过角色在数据湖构建平台集中实施 database 及 table 权限的管理
- 在数据湖构建平台、EMR引擎中分别访问有权限的表和没有权限的表
- 数据湖构建平台提供丰富的权限 api 供应用产品集成，用户可以加入自己的权限申请、审批流程
1. 采用阿里云主账号对阿里云 Ram 子账号进行admin/super_administrator 角色授权，以进行分权管理。
导航至数据湖构建-数据权限-角色页面，点击右侧添加用户按钮，选择待授权的 RAM 子账号，点击确定，进行子账号 admin 角色授权，如图：
完成后，子账号 test1 将拥有 admin 角色权限，test1 将从 admin 角色获得所有资源的访问和授权权限。后续可以通过 test1账号进行其他账号权限的管理。
2.使用 test1 账号登录，对子账号直接授权
导航至数据湖构建-数据权限-数据授权页面，点击新增授权，对子账号 data 授权 db1 的 Describe、CreateTable 权限，并授予该 db1 下所有除 Drop 外的表权限，在授权页面选择 data 用户并完成如下授权
完成后，data 将具备上述权限。
3.使用test1账号登录，创建角色，对角色授权，并将角色授予用户
创建数据湖构建角色test，并将该角色授予给子账号 datamigrator，同时给角色test 授权 db1 的 Describe 权限，并授予该 db1 下所有除 Select 外的表权限
此时各账户具备如下权限：
| 账号 | 拥有角色 | 权限 |
| test1 | admin | 拥有所有资源的访问和授权权限 |
| data | 拥有db1的 Describe、CreateTable、List拥有db1下所有表除 Drop 外的权限（默认拥有自己创建的表权限） | |
| datamigrator | test | 拥有db1的Describe、List权限拥有db1下所有表除Select外的权限 |
4.在数据湖平台上进行权限验证
在数据湖构建平台上使用 data 子账号访问相关元数据进行权限的验证，例如创建表，删除表，查询表.
1) 可正常创建表
test_create_table_from_data
2) 可正常删除自己创建的表
test_create_table_from_data
3) 删除其他用户创建的表 test_table，将报权限错误
4) 使用数据探索访问另一个db下的表，将报权限错误
5）用户可自行完成 datamigrator 权限的测试，此处不再过多演示。
5.在 EMR 集群进行权限的验证
1) 通过 Settings API（近期实现自动化），将EMR集群角色（可在 EMR 集群基础信息页面-ECS应用角色部分找到），添加为互信账号(修改之前通过 GetCatalogSettingsAPI 查看 Settings 内容，避免误修改):
{"Config": {"auth.super.principal": "acs:ram::[aliyunAccountId]:role/AliyunECSInstanceForEMRRole"}
}2）在 EMR 集群上，选择 DLF-Auth 组件并按下图所示，启用 hive/Presto/Spark 的鉴权
3）对鉴权进行验证
使用 data 用户通过 beeline 访问 Hiveserver 执行元数据操作，用户可自行进行其他语句的测试
6.其他应用及平台与数据湖元数据/权限 API 集成
数据湖构建平台提供丰富的权限 API 供应用产品集成，用户可以加入自己的权限申请、审批流程权限 API 列表见链接， 用户可选择将元数据 API 及权限 API 集成至自有权限审批平台，以完成自己的业务诉求。
总结
目前权限能力陆续在生态上进行集成，能够满足一部分场景需求，但还有一些局限，比如授权操作仅 admin 角色可进行资源授权，基于此我们将在近期推出 Grantable 权限，届时可以将资源的 Grant 权限授予给其他角色和用户，进一步实现权限分治，降低管理压力。另外数据湖构建产品未来将继续在多引擎生态、数据安全上发力，让数据湖构建产品具备更完善的生态和企业级的特性！
原文链接
本文为阿里云原创内容，未经允许不得转载。
