OSS-HDFS 细粒度权限管理与多业务访问管控

更新时间:
复制为 MD 格式

通过聚合 RAM 访问控制、EMR Ranger 和 Bucket QoS 资源池,实现 OSS-HDFS 的目录级权限控制、多业务访问隔离及按 RAM Role 的带宽流控,解决 Bucket 级权限粒度不足、多业务共享存储时资源抢占等问题。

前提条件

  1. OSS开通OSS-HDFS服务,并创建了启用 HDFS 特性的 Bucket。

  2. 创建EMR-5.21.0及之后或者EMR-3.55.0及之后版本的EMR集群,并选择安装RangerRanger-Plugin服务。

  3. 具备阿里云访问控制RAM 管理员权限。

方案原理

功能

实现原理

细粒度权限管理

通过 EMR Ranger 实现目录级别的细粒度权限配置。

多业务访问隔离

将业务拆分到不同的阿里云 RAM Role,配置 EMR Ranger 的 Client User 到业务 RAM Role 的映射关系,使 Client User 扮演不同 RAM Role 生成不同临时 AK 访问 OSS-HDFS,完成访问隔离。

业务级带宽流控

通过配置阿里云 Bucket QoS,为不同 RAM Role 配置 Bucket 的带宽流控,实现业务级带宽管控。

配置细粒度权限

  1. 登录 EMR 控制台

  2. 创建包含 Ranger 组件的 EMR 集群:

    • 集群版本:EMR-3.55.0 或 EMR-5.21.0 及更高版本

    • 集群类型:DATALAKE

    • 组件:Hadoop-Common、OSS-HDFS、Ranger、Ranger-Plugin、Zookeeper

    • 集群存储根路径:选择自建 Hadoop 集群需访问的 OSS-HDFS Bucket

    详见创建集群

    image

  3. 启用 OSS-HDFS 访问校验并配置细粒度权限,详见配置OSS/OSS-HDFS开启Ranger权限控制

配置多业务访问隔离与带宽流控

第一步:创建业务 RAM Role 并授权

  1. 登录 RAM控制台

  2. 进入身份管理 > 角色,创建 10 个 RAM 角色:jindoauth-qos-role-1 至 jindoauth-qos-role-10,用于访问 OSS-HDFS,随后为各角色授予 OSS-HDFS 访问权限。

    后续配置身份映射时,仅支持将集群本地用户(Client User)映射至此处创建的 RAM 角色(RAM Role),不支持映射到具体的 RAM 用户(RAM User)。
  3. 搜索 RAM 角色 AliyunECSInstanceForEMRRole(EMR 作业默认使用此角色访问 OSS-HDFS),为其授予扮演上述业务 RAM 角色的权限(AssumeRoleAccess)。

    image

第二步:配置 Client User 到 RAM Role 的映射

  1. 在 EMR 计算集群节点上创建 10 个 Client User:jindoauth-client-user-1 至 jindoauth-client-user-10

  2. EMR on ECS 控制台,进入集群服务 > Ranger,修改配置:

    • 修改 jindoauth-server 配置文件:

      配置项

      取值

      说明

      jindoauth.ram.role.mapping.enable

      true

      是否开启 RAM 映射

    • 修改 jindoauth-ram-role-mapping 配置文件,按以下格式配置映射。clientUser 为 EMR 集群用户名,ramRoleName 和 ramRoleArn 可在 RAM 控制台对应角色详情页获取:

      image

      <Configuration>
          <mapping>
              <clientUser>jindoauth-client-user-1</clientUser>
              <ramRoleName>jindoauth-qos-role-1</ramRoleName>
              <ramRoleArn>acs:ram::1**************6:role/jindoauth-qos-role-1</ramRoleArn>
          </mapping>
          <mapping>
              <clientUser>jindoauth-client-user-2</clientUser>
              <ramRoleName>jindoauth-qos-role-2</ramRoleName>
              <ramRoleArn>acs:ram::1**************6:role/jindoauth-qos-role-2</ramRoleArn>
          </mapping>
          <mapping>
              <clientUser>jindoauth-client-user-3</clientUser>
              <ramRoleName>jindoauth-qos-role-3</ramRoleName>
              <ramRoleArn>acs:ram::1**************6:role/jindoauth-qos-role-3</ramRoleArn>
          </mapping>
          <mapping>
              <clientUser>jindoauth-client-user-4</clientUser>
              <ramRoleName>jindoauth-qos-role-4</ramRoleName>
              <ramRoleArn>acs:ram::1**************6:role/jindoauth-qos-role-4</ramRoleArn>
          </mapping>
          <mapping>
              <clientUser>jindoauth-client-user-5</clientUser>
              <ramRoleName>jindoauth-qos-role-5</ramRoleName>
              <ramRoleArn>acs:ram::1**************6:role/jindoauth-qos-role-5</ramRoleArn>
          </mapping>
          <mapping>
              <clientUser>jindoauth-client-user-6</clientUser>
              <ramRoleName>jindoauth-qos-role-6</ramRoleName>
              <ramRoleArn>acs:ram::1**************6:role/jindoauth-qos-role-6</ramRoleArn>
          </mapping>
          <mapping>
              <clientUser>jindoauth-client-user-7</clientUser>
              <ramRoleName>jindoauth-qos-role-7</ramRoleName>
              <ramRoleArn>acs:ram::1**************6:role/jindoauth-qos-role-7</ramRoleArn>
          </mapping>
          <mapping>
              <clientUser>jindoauth-client-user-8</clientUser>
              <ramRoleName>jindoauth-qos-role-8</ramRoleName>
              <ramRoleArn>acs:ram::1**************6:role/jindoauth-qos-role-8</ramRoleArn>
          </mapping>
          <mapping>
              <clientUser>jindoauth-client-user-9</clientUser>
              <ramRoleName>jindoauth-qos-role-9</ramRoleName>
              <ramRoleArn>acs:ram::1**************6:role/jindoauth-qos-role-9</ramRoleArn>
          </mapping>
          <mapping>
              <clientUser>jindoauth-client-user-10</clientUser>
              <ramRoleName>jindoauth-qos-role-10</ramRoleName>
              <ramRoleArn>acs:ram::1**************6:role/jindoauth-qos-role-10</ramRoleArn>
          </mapping>
      </Configuration>

第三步:创建 OSS 资源池并配置 Bucket QoS

  1. 申请创建 OSS 资源池提交工单,示例参数如下:

    参数

    示例值

    UID

    1**************6

    地域

    华东 1(杭州)

    资源池

    cn-hangzhou-az-qos-resource-pool-1

    Bucket

    jindoauth-qos

    总上传带宽

    10 Gbps

    内网上传带宽

    10 Gbps

    外网上传带宽

    10 Gbps

    总下载带宽

    10 Gbps

    内网下载带宽

    10 Gbps

    外网下载带宽

    10 Gbps

  2. 配置 Bucket 分层流控:在资源池QoS页面,单击目标 Bucket 右侧的修改流控配置,设置 Bucket 总带宽。image

  3. 配置 RAM Role 请求者流控:在资源池 QoS 页面,单击目标资源池名称,再单击目标 Bucket 右侧的配置请求者流控,为各 RAM Role 设置带宽。请求者流控大于 0 时,最低为 5 Gbps。参考示例如下:

    RAM 角色

    流控阈值

    jindoauth-qos-role-1、jindoauth-qos-role-5、jindoauth-qos-role-10

    0 Gbps

    jindoauth-qos-role-2、jindoauth-qos-role-8

    5 Gbps

    jindoauth-qos-role-3、jindoauth-qos-role-9

    8 Gbps

    jindoauth-qos-role-4、jindoauth-qos-role-7、jindoauth-qos-role-8

    10 Gbps

    RAM Role对应的RAM ID配置的请求者流控配置后,控制台显示参考示例结果如下:

    image

验证效果

在云监控的对象存储OSS资源池中可查看各 RAM Role 的带宽流控结果。

云监控使用 OSS 推送的 10 秒聚合数据,显示流控峰值可能低于 OSS 实际流控值。

RAM 角色

流控阈值

测试结果

jindoauth-qos-role-1、jindoauth-qos-role-5、jindoauth-qos-role-10

0 Gbps

EMR 上所有访问 OSS 的请求均被限制,无内网带宽监控数据。

image

jindoauth-qos-role-2、jindoauth-qos-role-6

5 Gbps

内网下载带宽峰值约 4.8 Gbps,同时 EMR 上的请求日志显示被 QoS 流控。

image

jindoauth-qos-role-3、jindoauth-qos-role-9

8 Gbps

内网带宽峰值约 7.68 Gbps,同时 EMR 上的请求日志显示被 QoS 流控。

image

jindoauth-qos-role-4、jindoauth-qos-role-7、jindoauth-qos-role-8

10 Gbps

内网带宽峰值约 10 Gbps,同时 EMR 上的请求日志显示被流控。

image

生产环境建议

通过云监控创建报警规则,当带宽使用率超过 80% 时触发告警,便于及时调整带宽配置应对业务高峰。