COS Ranger 权限体系解决方案

Hadoop Ranger 权限体系是大数据场景下的权限解决方案。用户使用存算分离后，将数据托管在对象存储（Cloud Object Storage，COS）上。COS 使用的是腾讯云访问管理（Cloud Access Management，CAM）权限体系，无论是用户身份，权限策略等，都与本地 Hadoop Ranger 体系不同。为维持客户的使用习惯，我们提供 COS 的 Ranger 接入解决方案。

优势

细粒度的权限控制，兼容 Hadoop 权限逻辑，用户统一管理大数据组件与云端托管存储的权限。

插件侧无需在 core-site 中设置密钥，密钥统一在 COS Ranger Service 中设置，避免明文密钥的泄露。

解决方案架构







Hadoop 权限体系中，认证由 Kerberos 提供，授权鉴权由 Ranger 负责。在此基础上，我们提供以下组件，来支持 COS 的 Ranger 权限方案。

1. COS Ranger Plugin：提供 Ranger 服务端的服务定义插件。它们提供了 Ranger 侧的 COS 服务描述，包括权限种类，必要参数定义（例如 COS 的 bucket 参数和 region 参数）。部署了该插件后，用户即可在 Ranger 的控制页面上，填写相应的权限策略。

2. COS Ranger Service：该服务集成了 Ranger 的客户端，周期性从 Ranger 服务端同步权限策略，在收到客户的鉴权请求后，在本地进行权限校验。 同时它提供了 Hadoop 中 DelegationToken 相关的生成、续租等接口，所有的接口都是通过 Hadoop IPC 定义。

3. COS Ranger Client：COSN 插件对其进行动态加载，把权限校验的请求转发给 COS Ranger Service。

部署环境

Hadoop 环境。(需要3.2.2版本及以下)

ZooKeeper、Ranger。

Kerberos 服务。

说明：

以上服务由于是成熟的开源组件，因此客户可自行安装。组件之间，可能存在版本兼容性问题。这里推荐EMR-V350版本使用的组件版本。

Hadoop-3.2.2

Zookeeper-3.6.3

Ranger-2.3.0

Kerberos-1.15.1

部署组件

部署组件请按照 COS Ranger Plugin、COS Ranger Service、COS Ranger Client、COSN 次序进行。

部署 COS Ranger Plugin

部署 COS Ranger Service

部署 COS-Ranger-Client 和 COSN-Ranger-Interface

部署 COSN

COS-Ranger-Plugin 拓展了 Ranger Admin 控制台上的服务种类，用户可在 Ranger 控制台上，设置和 COS 相关的操作权限。

代码地址

可前往 Github 的 ranger-plugin 目录下获取。

版本

V1.0 版本及以上。

部署步骤

1. 在 Ranger 的服务定义目录下新建 COS 目录（注意，目录权限需要保证至少有 x 与 r 权限）。 a. 腾讯云的 EMR 环境，路径位于部署了ranger服务的Master节点的 /usr/local/service/ranger/ews/webapp/WEB-INF/classes/ranger-plugins。 b. 自建的 hadoop 环境，可以通过在 ranger 目录下查找 hdfs 等已经接入到 ranger 服务的组件，查找目录位置。





2. 在 COS 目录下，放入 cos-chdfs-ranger-plugin-xxx.jar。（注意 jar 包至少有 r 权限）。同时需要放入 cos-ranger.json 文件，可前往 Github 获取。

3. 重启 Ranger 服务。

4. 在 Ranger 上注册 COS 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 @./cos-ranger.json http://${rangerServerAddr}/service/plugins/definitions
##如果要删除刚定义的服务，则传入刚刚创建服务时，返回的服务 ID
serviceId=102
curl -v -u${adminUser}:${adminPasswd} -X DELETE -H "Accept:application/json" -H "Content-Type:application/json" http://${rangerServerAddr}/service/plugins/definitions/${serviceId}


5. 创建服务成功后，可在 Ranger 控制台看到 COS 服务。如下所示：





6. 在 COS 服务侧单击**+**，定义新服务实例，服务实例名可自定义，例如cos或者cos_test，服务的配置如下所示。



配置项需添policy.grantrevoke.auth.users和policy.download.auth.users。value设置后续启动 COS Ranger Service 服务的用户名（即允许拉取权限策略的用户）。通常建议设置成 hadoop，后续 COS Ranger Service 可使用此用户名进行启动。

7. 单击新生成的 COS 服务实例。



添加 policy，如下所示：





8. 在跳转界面中，配置以下参数，说明如下：

bucket：存储桶名称，例如 examplebucket-1250000000，可登录 COS 控制台 查看。

path：COS 对象路径。注意 COS 的对象路径不以/开始。

include：表示设置的权限适用于 path 本身，还是除了 path 以外的其他路径。

recursive：表示权限不仅适用于 path，还适用于 path 路径下的子成员（即递归子成员）。通常用于 path 设置为目录的情况。

user/group：用户名和用户组。这里是或的关系，即用户名或者用户组满足其中一个，即可拥有对应的操作权限。

Permissions：

Read：读操作。对应于对象存储里面的 GET、HEAD 类操作，包括下载对象、查询对象元数据等。

Write：写操作。对应于对象存储里面的 PUT 类等修改操作，例如上传对象。

Delete：删除操作。 对应于对象存储里删除 Object。对于 Hadoop 的 Rename 操作，需要有对原路径的删除操作权限，对新路径的写入操作权限。

List：遍历权限。对应于对象存储里面的 List Object。





验证

1. 使用 hadoop cmd 执行访问 COSN 的相关操作。查看当前用户执行的操作是否符合主账号的权限设置预期，示例如下所示：

#将bucket，路径等替换为主账号的实际信息。hadoop fs -ls cosn://examplebucket-1250000000/dochadoop fs -put ./xxx.txt cosn://examplebucket-1250000000/doc/hadoop fs -get cosn://examplebucket-1250000000/doc/exampleobject.txthadoop fs -rm cosn://examplebucket-1250000000/doc/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
    }
  }
}

接口的出参定义如下：

常见问题

如果开启了 Ranger，但未配置任何 Policy，或者未匹配到任何 Policy，会如何操作？

如果未匹配上任何 policy，会默认拒绝该操作。

配置 COS Ranger Service 侧的密钥可以是子账号？

可以是子账号，但是必须拥有被操作 bucket 的相应权限，才能生成临时密钥给到 COSN 插件，进行相应的操作。通常建议这里设置的密钥拥有对该 bucket 的所有权限。

临时密钥需如何更新，每次访问 COS 前都需要从 COS Ranger Service 侧获取?

临时密钥是 cache 在 COSN 插件侧，并周期性进行异步更新。

在 ranger 页面更改了 Policy 未生效怎么办？

请修改 ranger-cos-security.xml 文件的配置项：ranger.plugin.cos.policy.pollIntervalMs，调小该配置项（单位为毫秒），然后重启 COS Ranger Service 服务。Policy 相关测试结束后，建议修改回原来值（时间间隔太小导致轮询频率高，从而导致 CPU 负载高）。

其他认证和鉴权的问题可 点击此处 查看。