做100个网站效果,网站建设案例平台,开做网站的公司 条件,wordpress如何添加页面子目录下01 背景
随着云计算、大数据技术的日趋成熟#xff0c;复杂多元、规模庞大的数据所蕴含的经济价值和社会价值逐步凸显#xff0c;数据安全也是企业面临的巨大挑战#xff0c;B站一直致力于对用户隐私数据的保护。 02 Ranger概述 2.1 用户认证
提到安全#xff0c;就不得不… 01 背景
随着云计算、大数据技术的日趋成熟复杂多元、规模庞大的数据所蕴含的经济价值和社会价值逐步凸显数据安全也是企业面临的巨大挑战B站一直致力于对用户隐私数据的保护。 02 Ranger概述 2.1 用户认证
提到安全就不得不提及用户认证Hadoop默认是没有安全认证的用户可以伪装成任意用户访问集群存在巨大安全隐患。Hadoop 1.x 版本以后就已经加入了Kerberos认证机制只有经过认证的用户才可以访问集群目前我们数据平台的客户端及早期开放给用户的一些开发客户端已经全部接入了Kerberos。 2.2 Ranger介绍
Kerberos只是控制集群的登录相当于一把钥匙打开了进入集群操作的大门并没有实现用户操作权限的管理因此我们引入Ranger做权限管理。
Ranger提供一个集中式安全管理框架它可以对Hadoop生态的组件如HDFS、Yarn、Hive、HBase等进行细粒度的数据访问控制基本覆盖现有技术栈的组件。通过操作Ranger控制台和REST API可以轻松的通过配置策略来控制用户访问权限。
我们使用的Ranger是基于1.2.0版本改造的部署了2台写节点和2台读节点并接入公司的负载均衡系统来实现读写分离用户在申请Hive表或者HDFS path交接表或者交接任务时会发送请求给ShielderShielder是工具侧的授权服务授权时接入写节点的LBshielder会通过LB调用Ranger Admin的REST API进行权限操作Ranger Admin将相关policy持久化到DB赋权完成后Shielder还会通过LB调用读节点的REST API进行权限预检预检通过后用户申请权限的流程就结束了。
读节点的Ranger Admin会定时的从DB中全量load policyplugins在poll policy时Ranger Admin会将内存中的policy返回给嵌入在各个大数据组件的plugins。 03 HDFS Path鉴权 3.1 授权接口的改造
原生的Ranger授权接口需要传入RangerPolicy对于工具层需要给HDFS表路径或者非表路径授权比较繁琐因此我们改造了授权接口只需要传入四个参数如下 service : ranger service name用于识别service typepath或者table用于识别是为表赋权还是为路径赋权 resources具体的HDFS路径或者Hive表 access具体的权限类型read或者write
如果type是table会根据resources中的table通过Hive Metastore(HMS) client获取table location再根据路径查找相关policy是否存在来决定是更新还是创建。 3.2 Ranger Admin的改造
由于我们使用的Ranger版本需要全量load policy原生的Ranger Admin load policy是从DB中串行的读取数据读出来以后放在List中通过ListIterator将各部分的数据拼接成Policy拼接后如果检查到有的ListIterator还有next说明在读数据是有policy发生了变化需要重新读数据这样load policy的时间就不可控了。为了降低Admin load policy的时间我们将从DB中读数据的操作由串行改成并行我们使用Map存放Policy数据并取消了ListIterator对不齐时需要二次读数据的机制这样虽然可能会导致在读数据的时候新增的access可能匹配不上item但是在下一次读取的时候必然会匹配上一次load policy的误差是在我们的接受范围内的。由于我们使用Map做policy拼接读取item及access时的order by操作就可以取消了。
例如读access的query就由 select obj from XXPolicyItemAccess obj, XXPolicyItem item where obj.policyItemId item.id and item.policyId in (select policy.id from XXPolicy policy where policy.service :serviceId) order by item.policyId, obj.policyItemId, obj.order
变成 select obj from XXPolicyItemAccess obj, XXPolicyItem item where obj.policyItemId item.id and item.policyId in (select policy.id from XXPolicy policy where policy.service :serviceId) 目前我们HDFS有约18万的policy70万的policy item200万的policy item access去掉order by后load access可以节约4s左右的时间整体load policy的时间在25s左右。 3.3 灰度上线
为了鉴权可以优雅的上线减少因权限问题导致的任务失败我们在HDFS plugin端增加了鉴权模式支持按group一个部门对应一个group灰度上线鉴权功能鉴权模式分为ALWAYS_ALLOWALWAYS_DENY和BY_HADOOP_ACL鉴权时在没有匹配到policy的情况下才会用上述鉴权模式进行检查若模式为ALWAYS_ALLOW的情况下会检查user的group是不是在strict group中strict group可以通过配置文件配置支持hadoop命令刷新更新strict group配置后不用重启namenode就可以使其生效。在strict group中的user为严格鉴权如果没有相关policy会拒绝访问HDFS否则允许其访问同时打印越权日志可以根据越权日志决定为用户补权限。在所有的部门组灰度完成以后鉴权模式切换到ALWAYS_DENY即可。 3.4 权限预检
由于权限生效会有一定的延迟工具侧在调用Ranger api赋权以后没办法感知权限是否生效往往会发生工单流程已经走完用户还是没有的权限的情况。再者我们在排查user是否有一个路径权限时可能会因为父路径权限的影响排查起来会繁琐一些因此我们在Admin端开发了权限预检查的接口支持传入user库表及相应的权限类型返回权限检查是否成功。
根据传入的HDFS PathUser和Accesses的类型构建RangerAccessRequest通过RangerPolicyRepository的getLikelyMatchPolicyEvaluators方法获取evaluators遍历evaluators计算得到result。同时会启动一个 线程定时的从RangerServicePoliciesCache中获取ServicePolicies用于更新RangerPolicyRepository频率与plugin poll policy的频率相同。 04 Hive Table鉴权 4.1 HDFS鉴权的痛点
HDFS鉴权在使用的过程中遇到了一些问题比如table owner没有权限drop自己的表情况对于管理表来说drop表时会删除相应的表路径对于HDFS来说删除路径需要父路径的write权限但是该用户又没有库的写权限导致drop表失败。还有比如view的HDFS路径与相应表的HDFS路径是同一个如果只回收表的权限相当于回收了HDFS路径的权限用户即使还有view的权限在访问HDFS的时候就会失败。而且HDFS鉴权也只能到path级别无法进行更细粒度的鉴权和数据脱敏因此我们引入了Hive Table鉴权。 4.2 Hive授权接口
Ranger各个service之前的policy是相互独立的HDFS plugin在鉴权的时候只关心HDFS的policy因此我们在Hive的授权的同时会将Hive的权限类型转换成HDFS的权限为HDFS赋权。 4.3 Hive Metastore远程鉴权及数据脱敏
Ranger所有的Plugin的load policy的机制都是相同的需要请求Ranger Admin获取policy将Policy缓存到内存并持久化到磁盘这对于像HiveServer2Spark Thrift Server和Kyuubi这样的长服务来说是可以接受的但是对于像Hive Cli和Spark Sql这样的短任务load policy会消耗大量的时间内存和磁盘也会增加Ranger Admin的负载。
因此我们将鉴权和脱敏的功能放到Hive Metastore 中去做实现了一个类似于Hive Plugin的Hive MetaStore PluginHive Metastore新增了鉴权和脱敏两个接口。 鉴权
将鉴权的请求参数封装到CheckPrivilegesBag中无论是Hive还是Spark只要构建好CheckPrivilegesBag请求HMS即可。 struct CheckPrivilegesBag { 1: HiveOperationObjectType hiveOperationObjectType, // 操作类型 2: listHiveObjectPrivileges inputPrivileges, // 输入表信息 3: listHiveObjectPrivileges outputPrivileges, // 输出表信息 4: HiveAuthzContextObject hiveAuthzContext, 5: string user,} 脱敏
row filter和column masking需要传入HiveAuthzContextObjectlistHiveObjectPrivileges和user。 listHiveObjectPrivileges apply_row_filter_and_column_masking(1:HiveAuthzContextObject hiveAuthzContextObject, 2: listHiveObjectPrivileges objectPrivileges, 3: string user) throws(1:MetaException o1) 4.4 Spark Ranger
Spark Ranger是通过inject Rule和Strategy解析plan来实现鉴权和脱敏的改造成通过HMS鉴权需要将SparkOperationType和SparkPrivilegeObject转换成对应的HiveOperationType和HivePrivilegeObject。
由于用来鉴权的RangerSparkAuthorizerExtension Rule可能会被执行多次会做一些不必要的鉴权带来额外的时间开销查询表比较多的query在耗时上会更加明显。我们会将鉴权成功的输入表/字段和输出表/字段的相关信息缓存起来下一次鉴权时首先剔除掉缓存中已通过鉴权的表/字段如果剩余的不为空再继续请求HMS鉴权
目前我们Spark和Hive已经全接入了HMS鉴权和数据脱敏对于数据脱敏中的column masking我们正在用的策略部分有 另外我们在使用spark ranger做column masking的时候也遇到了一些问题比如对于sql select col_1, col_2 from tbl_1 union select col_3, col_4 from tbl_2 如果col_2和col_4的policy是不同的终col_4的数据也会使用col_2的making policy因为spark ranger的做法是在外层加一个Project这样就会导致col_4的policy失效。 我们将Project推到Relation层替换掉有making的column在Project中将经过masking处理后的column cast成原始的column执行计划就变成 4.5 Presto Ranger
鉴于Presto Coordinator为常驻服务从Ranger Admin获取并加载policy所带来的消耗是可接受的因此我们在Presto Ranger Plugin上进行改造。社区鉴权逻辑为首先定期请求Ranger Admin获取Presto相关的policy并将其拉取到本地其次在Presto每次进行语义分析的时候对当前表及字段的权限进行校验。对上述鉴权逻辑进行分析我们不难发现社区的鉴权方式需要在Admin侧单独维护Presto相关的policy而在我们的场景中大部分的权限需求还是在Hive中为不同引擎各自维护一套policy无疑会增加运维成本因此我们对其做了些改造使其兼容Hive的policy。其实现方式并不复杂一方面将拉取Presto policy替换为拉取Hive policy另一方面将原先Presto plugin的3段式进行改造兼容Hive的格式。目前我们的Presto Ranger支持了表/字段、column masking和row filter的权限控制。 05 未来规划 5.1 增量Load Policy
即使我们优化了load policy的逻辑plugin权限生效的时间也要在25s以上而且随着policy的增加这个时间还将进一步增加Ranger-2.0.0版本已经支持了增量Load Policy功能下半年我们也会参考社区做增量化改造降低权限生效时间预估能到1s内。 5.2 HDFS融合Hive Policy
Hive鉴权通过以后任务访问HDFS还需要再经过HDFS的鉴权这样就需要维护Hive和HDFS两份Policy而且也不能解决前面提到的table owner无法删除自己的表的情况下一步我们会将Hive Policy与HDFS Plugin融合起来HDFS Plugin中维护一份table location数据在检查路径权限时首先检查路径对应的Hive Table是否有相应的权限如果有就可以通过权限检查如果没有匹配到table再检查HDFS Policy。 5.3 HDFS鉴权前置到NNProxy
目前我们HDFS有20组的NS每一组NS都要连接Ranger Admin获取policy无疑增加了Ranger Admin的压力后面我们考虑将HDFS鉴权的操作前置到NNProxy中去做同时也能降低NameNode的处理时间。
