35 篇文档带有标签「ranger」

看了一些文章, 主要有两个思路.

hdfs的用户和用户组关系其实是有缓存的, 使用google的guava cache缓存, 默认缓存时间是300秒.

看了一遍hdfs和ranger权限部分的代码, 大概清楚ranger是如何嵌入hdfs的鉴权流程了.

之前讨论spark的ranger权限管控问题的时候, 就提到hive server2 ranger插件只对经过hive server2的请求生效, 如果spark等应用直接读取hive metatore, ranger hive插件那就无法管控到了. 业内有一些解法, 可以从组件自身的解析流程入手, 比如解析spark logical plan转化为对应的元数据操作权限请求, 也可以从hive metastore入手限制权限, 不过一直看到的讨论都是hive metastore的权限管控还不成熟. 这次看ranger官方文档, 发现在hive4版本之后, metastore算是正式支持鉴权了. 这时候有另一个问题, hive server2插件还有存在的必要吗?

其他文档已经把hive server2相关的ranger策略讲得差不多了.

spark 自身的thrift server据说不支持用户资源隔离(个人没有测试研究), 国内网易开源的 apache kyuubi 提供了租户隔离和资源隔离的解决方法. 看了下源码仓库, 还支持了ranger鉴权, spark血缘解析, 一套数据治理方案直接打包了. 如果kyuubi确实稳定可用, 可以省去很多使用spark的数据治理的麻烦.

kyuubi ranger

General

选择策略的时候, 配置用户权限里有个选项可以勾选“Delegate Admin", 每次看到都有点疑惑, 用户已经限制了权限, 为什么还能“代表管理员”呢?

ranger elasticsearch 连接使用

看impala的ranger插件代码, 才知道原来ranger还能这么玩. 支持create role, grant privilege权限,看起来跟mysql的grant语法一样, 背后其实自动转换调用ranger api创建policy.

列脱敏和行筛选, 没想到都是数据权限管控的领域, 都是ranger提供的基本功能. 使用起来非常直观, 基本原理以前也看过一些文档了, 实现方案都是改写sql, 但是没看到技术细节没看到代码还是不稳妥. 浏览ranger 鉴权代码的时候, 也没看到怎么改写hive sql的内容, 总觉得世界的迷雾没有破开. 一番搜索, 发现原来底层是hive实现的, ranger基本上只提供了策略的管理和调用. 这套流程嵌入在hive的checkPrivilege鉴权请求流程里, 打得一手好配合.

看了各种源码, 还是需要动动手测试下才行, 不然压根不知道各种corner case是怎么回事. get your hands dirty.

ranger hive shou tables 权限问题

看了下impala源码, 自带了对ranger的支持, 在执行sql的时候可以调用ranger的鉴权逻辑, 并不需要通过hive server进行ranger代理触发. 看起来impala plugin用的还是hive的policy, 因此估计可以一份ranger policy配置, hive与impala同时生效.

ranger中毫无用处的单元测试

hive plugin policy的定义

ranger cache 缓存就是保存在大数据组件ranger plugin的服务器上, plugin鉴权不用再去访问ranger admin, 难怪速度可以满足要求.

原来ranger在plugin里构建的是一颗trie树, 根据request请求体里的访问资源, 快速查找匹配的policy权限定义, 然后判断是否有权限.

ranger ui界面里有不少security zones的交互, 但是没有使用需求也就没有去了解. 这次阅读ranger的官方文档, 顺便把一些基础功能扫了一遍. 其实security zones有点类似于授权策略里的delegate as admin, 在划分的元数据里进行权限的管理. 每个区域的管理员, 只能管理这个区域的授权信息, 算是大公司里的一个常见需求. 操作步骤首先是对元数据进行划分, 比如按照某几个库某几个表进行拆分, 其次是设置管理员, 然后设置权限即可. 元数据区域的划分需要正交, 也即没有交集.

初步调研结论

看起来策略都保存在x_policy表中，所有信息都通过json序列化为text。

到处看一看, 底层搬砖人总是在重复.

分类分级系统, 跟标签策略系统真是绝配.

apache ranger 执行mvn package编译或是测试, 都会报错karma插件问题.

有一个现象, 修改 ranger policy 之后, 下一个 read policy 的 ranger api 请求耗时总是非常长, 容易导致依赖模块的 api 超时.

看起来ranger hive plugin只需要在hive的插件里设置 row filter regex正则, column mask expression 脱敏表达式, 真正的实现倒像是由hive自身完成了. 咨询了chatgpt, 说是由ranger提前修改的sql, 还得再看看.

看ranger源码发现个小问题, 业务逻辑里只修改两行代码, 于是直接发起了jira issue, 同时在github发起pr.

ranger plugin 组件里的ranger插件初始化的时候, init方法就会启动线程定时从ranger admin server里下载policy策略.

开启 ranger hdfs audit 确认需要的 hdfs 权限

表g005有字段a和字段b

随手记录, 主要都是在配置文件里写好类名, 然后classFor读取记载.

在调用curl命令请求ranger的时候, 命令行里需要写入账号密码 curl -u username:password, 不知道这是不是通用的一种技术规范. 咨询了chatgpt, 发现其实就是标准的 basic auth 简单加密.

docker ranger 编译

2023-06-28