背景
大数据用户使用存算分离后，将数据托管在云 HDFS（Cloud HDFS，CHDFS）上。CHDFS 提供了类似 HDFS 的权限体系管控。Hadoop Ranger 在 HDFS 权限基础上，提供了更精细的权限管控，包括用户组权限设置，针对某个前缀的权限设置。同时 Hadoop Ranger 作为一站式的权限体系解决方案， 不仅支持存储端权限管控，还支持 YARN，Hive 等组件权限管控。因此，为了维持方便客户的使用习惯，我们提供了 CHDFS 的 Ranger 接入解决方案，方便客户使用 Ranger 来进行 CHDFS 的权限管控。
优势
细粒度的权限控制，兼容 Hadoop 权限习惯。
用户统一管理大数据组件与云端托管存储的权限。
解决方案架构
Hadoop 权限体系中，认证由 Kerberos 提供，授权鉴权由 Ranger 负责。在此基础上，我们提供以下组件，来支持 CHDFS 的 Ranger 权限方案。
CHDFS-Ranger-Plugin：提供 Ranger 服务端的服务定义插件。它们提供了 Ranger 侧的 CHDFS 服务描述，部署了该插件后，用户即可在 Ranger 的控制页面上，填写相应的权限策略。
COSRangerService：该服务集成了 Ranger 的客户端，周期性从 Ranger 服务端同步权限策略，在收到客户的鉴权请求后，在本地进行权限校验。 同时它提供了 Hadoop 中 DelegationToken 相关的生成，续租等接口，所有的接口都是通过 Hadoop IPC 定义。
CosRangerClient：COSN/CHDFS 插件对其进行动态加载，把权限校验的请求转发给 CosRangerService。
部署环境
Hadoop 环境。
ZooKeeper、Ranger、Kerberos 服务（如果有认证需求，则部署）。
说明
以上服务由于是成熟的开源组件，因此客户可自行安装。
部署组件
部署组件请按照 CHDFS-Ranger-Plugin、Cos-Ranger-Service、Cos-Ranger-Client、CHDFS 次序进行。
CHDFS-Ranger-Plugin 拓展了 Ranger Admin 控制台上的服务种类， 用户可在 Ranger 控制台上，设置和 CHDFS 相关的操作权限。
代码地址
版本
V1.0版本及以上。
部署步骤
1. 在 Ranger 的服务定义目录下新建 COS 目录（注意：目录权限需要保证至少有 x 与 r 权限）。
2. 腾讯云的 EMR 环境，路径是 ranger/ews/webapp/WEB-INF/classes/ranger-plugins。
3. 自建的 hadoop 环境，可以通过在 ranger 目录下 find hdfs 等方式找到已经接入到 ranger 服务的组件，查找 ranger-plugins 目录位置。
4. 在 CHDFS 目录下，放入 cos-chdfs-ranger-plugin-xxx.jar（注意： jar 包至少有 r 权限）。若使用 CHDFS 服务，需要在机器上放入 chdfs-ranger.json；若使用 COSN 服务，需要放入 cos-ranger.json；若同时使用 CHDFS 和 COSN 服务，需要同时放入 chdfs-ranger.json 和 cos-ranger.json 文件，可前往 Github 获取。
5. 重启 Ranger 服务。
6. 在 Ranger 上注册 CHDFS Service。可参考如下命令：
##生成服务，需传入 Ranger 管理员账号密码，以及 Ranger 服务的地址。##对于腾讯云 EMR 集群，管理员用户是 root，密码是构建 emr 集群时设置的 root 密码，ranger 服务的 IP 换成 EMR 的 master 节点 IP。adminUser=root##构建 EMR 集群时设置的密码，也是 ranger 服务 web 页面的登录密码。adminPasswd=xxxxxx##如果 ranger 服务有多个 master 节点，任选一个 master 即可rangerServerAddr=10.0.0.1:6080##命令行中 -d 指定步骤 2 中的 json 文件curl -v -u${adminUser}:${adminPasswd} -X POST -H "Accept:application/json" -H "Content-Type:application/json" -d @./chdfs-ranger.json http://${rangerServerAddr}/service/plugins/definitions##如果要删除刚定义的服务，则传入刚刚创建服务时，返回的服务 IDserviceId=102curl -v -u${adminUser}:${adminPasswd} -X DELETE -H "Accept:application/json" -H "Content-Type:application/json" http://${rangerServerAddr}/service/plugins/definitions/${serviceId}
7. 创建服务成功后，可在 Ranger 控制台看到 CHDFS 服务（以 CHDFS 为例，COSN 类似）。如下所示：
8. 在 CHDFS 服务侧单击【+】，定义新服务实例，服务实例名可自定义，例如 
chdfs 或者 chdfs_test。服务的配置如下所示：
9. 单击新生成的 CHDFS 服务实例。
10. 在跳转界面中，配置以下参数。具体说明如下：
MountPoint: 挂载点的名称，格式为 f4mxxxxxx-yyyy 等样式，可登录 CHDFS 控制台 查看。
path: CHDFS 路径。注意 CHDFS 路径必须以
/开始。include：表示设置的权限适用于 path 本身，还是除了 path 以外的其他路径。
recursive：表示权限不仅适用于 path，还适用于 path 路径下的子成员（即递归子成员）。通常用于 path 设置为目录的情况。
user/group：用户名和用户组。这里是或的关系，即用户名或者用户组满足其中一个，即可拥有对应的操作权限。
Permissions：
Read：读操作。对应于对象存储里面的 GET、HEAD 类操作，包括下载对象、查询对象元数据等。
Write：写操作。对应于对象存储里面的 PUT 类等修改操作，例如上传对象。
Delete：删除操作。 对应于对象存储里删除 Object。对于 Hadoop 的 Rename 操作，需要有对原路径的删除操作权限，对新路径的写入操作权限。
List：遍历权限。对应于对象存储里面的 List Object。
COS-Ranger-Service 是整个权限体系的核心，负责集成 ranger 的客户端，接收 ranger client 的鉴权请求，token 生成续租请求和临时密钥生成请求。同时也是敏感信息（腾讯云密钥信息）所在的区域，通常部署在堡垒机器上，只允许集群管理员操作，查看配置等。
COS-Ranger-Service 支持多节点的HA 部署，DelegationToken 状态持久化到 DB上。通过 ZK 互相感知彼此节点的存在。通过客户端配置的任何一个的cos-ranger-server 的地址， 即可知道全量的列表。 因此可以通过平行扩容 cos-ranger-server，来提升整体的鉴权能力。
代码地址
版本
V6.0版本及以上。
部署步骤
1. 将 COS Ranger Service 服务代码拷贝到集群的几台机器上，生产环境建议至少两台机器。因为涉及到敏感信息，建议是堡垒机或者权限严格管控的机器。
2. 如果是 kerberos 集群, 则需要一个 db 来保存 Delegation Token（有关 kerberos 的 Delegation token 的作用, 搜索相关博文即可）， db 规格推荐16c32g，100g磁盘以上。在负载不高的集群上，可混用 Hive meta store 的 db。 初始化 database 和表的 sql 语句可前往 Github 的 cos-ranger-server/sql 目录下获取.
3. 修改 cos-ranger.xml 文件中的相关配置，其中必须修改的配置项如下所示。配置项说明请参见文件中的注释说明（配置文件可前往 Github 的 cos-ranger-server/conf 目录下获取）。
qcloud.object.storage.rpc.address
qcloud.object.storage.status.port
qcloud.object.storage.enable.chdfs.ranger
qcloud.object.storage.zk.address （zk 地址，cos ranger service 启动后注册到 zk 上）
qcloud.object.storage.kerberos.principal (kerberos 集群下的 principal, 非 kerberos 请忽略)
qcloud.object.storage.kerberos.keytab (kerberos 集群下的 keytab 文件, 非 kerberos 请忽略)
sql-dt-secret-manager.connection.url (kerberos 集群, 保存 delegation token 的 db, 非 kerberos 请忽略)
sql-dt-secret-manager.connection.username (kerberos 集群, 访问 delegation token 的 db 的用户名, 非 kerberos 请忽略)
hadoop.security.credential.provider.path (kerberos 集群, 访问 delegation token 的 db 的用户密码的 jceks 文件路径, 非 kerberos 请忽略)
4. 修改 ranger-chdfs-security.xml 文件中的相关配置。其中必须修改的配置项有如下所示。配置项说明请参见文件中的注释说明（配置文件可前往 Github 的 cos-ranger-server/conf 目录下获取）。
ranger.plugin.chdfs.policy.cache.dir
ranger.plugin.chdfs.policy.rest.url
ranger.plugin.chdfs.service.name
5. 修改 start_rpc_server.sh 中 hadoop_conf_path 和 java.library.path 的配置。这两个配置分别指向 hadoop 配置文件所在的目录（例如 core-site.xml、hdfs-site.xml）以及 hadoop native lib 路径。
6. 执行如下命令启动服务。
chmod +x start_rpc_server.shnohup ./start_rpc_server.sh &> nohup.txt &
7. 如果启动失败，查看 log 下 error 日志是否有错误信息。
8. cos-ranger-service 支持展示 HTTP 端口状态（端口名为 qcloud.object.storage.status.port，默认值为9998）。用户可通过以下命令获取状态信息（例如目前全量的 cos-ranger-server 列表、鉴权数量统计等）。
# 请将下面的10.xx.xx.xxx 替换为部署 ranger service 的机器 IP# port 9998 设置为 qcloud.object.storage.status.port 配置值curl -v http://10.xx.xx.xxx:9998/status
COS-Ranger-Client 由 hadoop chdfs 插件动态加载，并代理访问 COS-Ranger-Service 的相关请求。例如获取 token、鉴权操作等。
代码地址
版本
cos-ranger-client 要求 V6.0版本及以上。cosn-ranger-interface 要求 v1.0.5版本及以上。
腾讯云 EMR 环境中默认安装目录在 common/lib 下，例如 /usr/local/service/hadoop/share/hadoop/common/lib 下。请根据自己的环境，放在对应的common/lib 路径下。 对于 ranger-client 的包名，例如 hadoop-ranger-client-for-hadoop-2.8.5-6.0.jar，2.8.5 是 hadoop 版本号，6.0是该包的版本号。for-hadoop 是通常组件使用的版本，其他一些组件，例如 presto， impala 以及高版本的 spark(spark-3.2.0版本及以后) 等，由于对依赖的 hadoop-common做了 shade，因此 ranger-client 也必须做 shade，否则会报类找不到。这些包请下载对应的 for-presto, for-impala, for-spark 版本等。
部署方式
1. 将 cos-ranger-client jar 包和 cosn-ranger-interface jar 包拷贝到与 CHDFS 插件同一目录下（通常在 /usr/local/service/hadoop/share/hadoop/common/lib/ 目录下；请选择拷贝与自身 hadoop 大版本一致的 jar 包，最后确保 jar 包有可读权限）。
2. 在 core-site.xml 添加如下配置项：
```<configuration><!--*****必须配置********--><!-- 上一步部署的 cos ranger server 的地址 --><property><name>qcloud.object.storage.ranger.service.address</name><value>10.0.0.8:9999,10.0.0.10:9999</value></property><!--***可选配置****--><!-- 设置 cos ranger service 端用的 kerberos 凭据，参考 cos ranger service 端的配置，须保持一致，如果没有认证的需求，不需要配置 --><property><name>qcloud.object.storage.kerberos.principal</name><value>hadoop/_HOST@EMR-XXXX</value></property></configuration>```
版本
V3.3版本及以上。
部署方式
```<property><name>fs.ofs.ranger.enable.flag</name><value>true</value></property>```
验证
1. 使用 hadoop cmd 执行访问 chdfs 的相关操作。 如下所示：
# 将挂载点，路径等替换为自己的实际信息。hadoop fs -ls ofs://f4mxxxxyyyy-zzzz.chdfs.ap-guangzhou.myqcloud.com/dochadoop fs -put ./xxx.txt ofs://f4mxxxxyyyy-zzzz.chdfs.ap-guangzhou.myqcloud.com/doc/hadoop fs -get ofs://f4mxxxxyyyy-zzzz.chdfs.ap-guangzhou.myqcloud.com/exampleobject.txthadoop fs -rm ofs://f4mxxxxyyyy-zzzz.chdfs.ap-guangzhou.myqcloud.com/exampleobject.txt
2. 使用 MR Job 进行验证，验证前需重启相关的服务，例如 Yarn、Hive 等。
获取统计信息
可以通过以下 curl 命令手动获取 COS Ranger 的统计信息：
curl http://${ranger_ip}:9998/status | jq# 返回{"allMemberAddress": "10.0.0.7:9999",//集群中所有成员的地址"currentNodeIsLeader": true, // 当前节点是否是leader节点"leaderAddress": "10.0.0.7:9999", // leader地址(对于客户端v5.x版本有意义，v6.x后是全对等模式，leader信息没有意义"authStat": {// 自定义鉴权认证的次数统计信息(对于为实现自定义认证的服务，始终是认证成功)"authSuccessStat": { // 认证成功统计信息"qps_5m": 0,// 最近 5 分钟的每秒查询数（QPS）"total_1m": 0,//最近 1 分钟的总成功认证次数"qps_1m": 0,// 最近 1 分钟的每秒查询数"total_5m": 0,//最近 5 分钟的总成功认证次数"qps": 0//当前的每秒查询数},"authFailedStat": {// 鉴权认证失败统计信息,字段含义与 authSuccessStat 相同"qps_5m": 0,"total_1m": 0,"qps_1m": 0,"total_5m": 0,"qps": 0}},"rpcMethodStat": {//包含不同 RPC 方法的调用次数的统计信息"checkPermission": {//检查权限的方法统计信息"qps_5m": 10,"total_1m": 3000,"qps_1m": 50,"total_5m": 3000,"qps": 1000},"getAvailableService": {//获取可用服务的方法统计信息"qps_5m": 0,"total_1m": 1,"qps_1m": 0.02,"total_5m": 1,"qps": 0}},"checkPermissionAllowAfterRetryCnt": 0,// 经过重试后允许的权限检查次数"checkPermissionAllowCnt": 4000,//允许的权限检查总次数"becomeLeaderTime": "2024-12-10T12:56:52.888Z",//当前节点成为leader的时间"checkAuthDenyCnt": 0,//被拒绝的认证检查次数"serviceStartTime": "2024-12-10T12:56:52.884Z",//服务启动的时间"checkPermissionDenyCnt": 0,//被拒绝的权限检查次数"accessStat": {//包含不同访问类型的统计信息"READ": {//读取操作的统计信息"qps_5m": 10,"total_1m": 3000,"qps_1m": 50,"total_5m": 3000,"qps": 1000}},"checkCostStat": {//checkPermission(检查权限)耗时的统计信息"checkFailStat": {//失败"avg_5m": 0,"min_1m": 0,"avg": 0,"min": 0,"max": 0,"max_1m": 0,"avg_1m": 0,"max_5m": 0,"min_5m": 0},"checkSuccessStat": {//成功"avg_5m": 5,//最近 5 分钟的平均耗时"min_1m": 0,//最近1分钟最小耗时"avg": 4,//平均耗时"min": 0,//最小耗时"max": 1263,//最大耗时"max_1m": 1263,//最近一分钟最大耗时"avg_1m": 5,//最近一分钟平均耗时"max_5m": 1263,//最近五分钟最大耗时"min_5m": 0//最近五分钟最小耗时}},"authCostStat": {// 权限认证耗时统计"authSuccessStat": {"avg_5m": 0,"min_1m": 0,"avg": 0,"min": 0,"max": 0,"max_1m": 0,"avg_1m": 0,"max_5m": 0,"min_5m": 0},"authFailedStat": {"avg_5m": 0,"min_1m": 0,"avg": 0,"min": 0,"max": 0,"max_1m": 0,"avg_1m": 0,"max_5m": 0,"min_5m": 0}},"rpcMethodCostStat": {//RPC接口耗时统计"checkPermission": {"avg_5m": 5,"min_1m": 0,"avg": 4,"min": 0,"max": 1263,"max_1m": 1263,"avg_1m": 5,"max_5m": 1263,"min_5m": 0},"getAvailableService": {"avg_5m": 280,"min_1m": 280,"avg": 280,"min": 280,"max": 280,"max_1m": 280,"avg_1m": 280,"max_5m": 280,"min_5m": 280}},"statsTimestamp": "2024-12-12T05:28:38.688Z",//统计时间"checkStat": {// check policy统计信息"checkFailStat": {"qps_5m": 0,"total_1m": 0,"qps_1m": 0,"total_5m": 0,"qps": 0},"checkSuccessStat": {"qps_5m": 10,"total_1m": 3000,"qps_1m": 50,"total_5m": 3000,"qps": 1000}}}
接口的出参定义如下：
一级字段 | 二级字段 | 三级字段 | 字段含义 |
serviceStartTime | - | - | 服务启动时间 |
currentNodeIsLeader | - | - | 当前节点是否是 leader |
becomeLeaderTime | - | - | 成为 leader 时间 |
statsTimestamp | - | - | 统计时间 |
leaderAddress | - | - | leader 地址 |
allMemberAddress | - | - | 集群内所有成员地址 |
checkPermissionAllowCnt | - | - | check permission 成功数 |
checkAuthDenyCnt | - | - | 认证鉴权失败数 |
checkPermissionDenyCnt | - | - | check permission 失败数 |
checkPermissionAllowAfterRetryCnt | - | - | 重试后check permission 成功数 |
accessStat | - | - | 操作统计 |
accessStat | LIST | - | List 操作次数 |
accessStat | WRITE | - | Write 操作次数 |
accessStat | READ | - | Read 操作次数 |
accessStat | DELETE | - | Delete 操作次数 |
authStat | - | - | 认证统计 |
authStat | authSuccessStat | qps、qps_1m、qps_5m、count_1m、count_5m | 认证成功统计 |
authStat | authFailedStat | qps、qps_1m、qps_5m、count_1m、count_5m | 认证失败统计 |
authCostStat | - | - | 认证耗时统计 |
authCostStat | authSuccessStat | max、min、avg、max_1m、min_1m、avg_1m、max_5m、min_5m、avg_5m | 认证成功耗时统计 |
authCostStat | authFailedStat | max、min、avg、max_1m、min_1m、avg_1m、max_5m、min_5m、avg_5m | 认证失败耗时统计 |
checkStat | - | - | check permission 统计 |
checkStat | checkSuccessStat | qps、qps_1m、qps_5m、count_1m、count_5m | check permission 成功统计 |
checkStat | checkFailStat | qps、qps_1m、qps_5m、count_1m、count_5m | check permission 失败统计 |
checkCostStat | - | - | check permission 耗时统计 |
checkCostStat | checkSuccessStat | max、min、avg、max_1m、min_1m、avg_1m、max_5m、min_5m、avg_5m | check permission 成功耗时统计 |
checkCostStat | checkFailStat | max、min、avg、max_1m、min_1m、avg_1m、max_5m、min_5m、avg_5m | check permission 失败耗时统计 |
rpcMethodStat | - | - | rpc 方法统计 |
rpcMethodStat | getDelegationToken | qps、qps_1m、qps_5m、count_1m、count_5m | getDelegationToken 方法统计 |
rpcMethodStat | renewDelegationToken | qps、qps_1m、qps_5m、count_1m、count_5m | renewDelegationToken 方法统计 |
rpcMethodStat | cancelDelegationToken | qps、qps_1m、qps_5m、count_1m、count_5m | cancelDelegationToken 方法统计 |
rpcMethodStat | verifyDelegationToken | qps、qps_1m、qps_5m、count_1m、count_5m | verifyDelegationToken 方法统计 |
rpcMethodStat | checkPermission | qps、qps_1m、qps_5m、count_1m、count_5m | checkPermission 方法统计 |
rpcMethodStat | getSTS | qps、qps_1m、qps_5m、count_1m、count_5m | getSTS 方法统计 |
rpcMethodStat | getRangerAuthPolicy | qps、qps_1m、qps_5m、count_1m、count_5m | getRangerAuthPolicy 方法统计 |
rpcMethodStat | getAvailableService | qps、qps_1m、qps_5m、count_1m、count_5m | getAvailableService 方法统计 |
rpcMethodCostStat | | | RPC 方法耗时统计 |
rpcMethodCostStat | getDelegationToken | max、min、avg、max_1m、min_1m、avg_1m、max_5m、min_5m、avg_5m | getDelegationToken 方法统计 |
rpcMethodCostStat | renewDelegationToken | max、min、avg、max_1m、min_1m、avg_1m、max_5m、min_5m、avg_5m | renewDelegationToken 方法统计 |
rpcMethodCostStat | cancelDelegationToken | max、min、avg、max_1m、min_1m、avg_1m、max_5m、min_5m、avg_5m | cancelDelegationToken 方法统计 |
rpcMethodCostStat | verifyDelegationToken | max、min、avg、max_1m、min_1m、avg_1m、max_5m、min_5m、avg_5m | verifyDelegationToken 方法统计 |
rpcMethodCostStat | checkPermission | max、min、avg、max_1m、min_1m、avg_1m、max_5m、min_5m、avg_5m | checkPermission 方法统计 |
rpcMethodCostStat | getSTS | max、min、avg、max_1m、min_1m、avg_1m、max_5m、min_5m、avg_5m | getSTS 方法统计 |
rpcMethodCostStat | getRangerAuthPolicy | max、min、avg、max_1m、min_1m、avg_1m、max_5m、min_5m、avg_5m | getRangerAuthPolicy 方法统计 |
rpcMethodCostStat | getAvailableService | max、min、avg、max_1m、min_1m、avg_1m、max_5m、min_5m、avg_5m | getAvailableService 方法统计 |
常见问题
如果开启了 Ranger，但未配置任何 Policy，或者未匹配到任何 Policy，会如何操作？
如果未匹配上任何 policy，会默认拒绝该操作。
开启了 ranger 后，CHDFS 端是否还会进行 POSIX 鉴权？
Ranger 鉴权是在客户端环境进行的，经过 ranger 鉴权的请求，会发给 CHDFS 服务端，服务端默认会进行 POSIX 鉴权。因此如果权限都在 Ranger 端进行控制，请在 CHDFS 控制台关闭 POSIX 权限。
在 ranger 页面更改了 Policy 未生效怎么办？
请修改 cos-ranger-server 服务目录 conf 下的 ranger-chdfs-security.xml 文件的配置项：ranger.plugin.chdfs.policy.pollIntervalMs，调小该配置项（单位为毫秒），然后重启 cos-ranger-service 服务。Policy 相关测试结束后，建议修改回原来值（时间间隔太小导致轮训频率高，从而导致 CPU 利用率高企）。
其他认证和鉴权的问题可 点击此处 查看。
