ranger插件开发（上）

Apache ranger 是一个集中式的安全管理框架，用户可以登录到ranger的web控制台配置不同的策略，实现对hadoop相关生态组件细粒度的权限控制。

最新版本（2.1.0）支持的组件包括hdfs、yarn、hbase、hive、kafka等。而ranger内部等stack-model实现方式，使得在ranger中支持一个新的服务非常方便。

在ranger中添加一个新的服务，最重要的是对该服务进行描述，包括服务的名称，需要进行权限控制的资源、对资源的访问类型等等。这些都定义在一个配置文件中。本文就来详细说说如何编写这个配置文件。

服务定义配置文件是一个JSON格式描述的文件，在该文件中，通常会包含这么些字段：

• id 服务的ID，对应数据库表中的一个字段，必须唯一。即不同的服务不能使用同一id。
• name 服务的名称。不能为空，不能和其他服务的名字相同。
• displayName 在ranger的web界面中显示的名称。
• implClass 在ranger admin内部对应的实现类。
• label 服务的标签名，对应数据库表中的一个字段。
• description 服务的描述，也对应数据库表中的一个字段。
• guid 唯一的ID。
• resources 服务需要用来进行权限校验的资源列表。
• accessTypes 资源需要进行校验的访问类型列表。
• configs 用于连接到具体的服务进行资源的检索。
• enums configs中枚举类型的定义。
• contextEnrichers 内容扩展字段，通常为空。
• policyConditions 策略配置时的条件选项，例如额外配置条件对指定ip段生效。
• dataMaskDef 一般用于数据库类型的服务中，对结果数据进行筛选处理。例如展示部分字段用于脱敏。
• rowFilterDef 同样用于数据库类型的服务中，定义对行数据的过滤处理。

部分字段会直接体现在ranger的web界面中，如下图所示：

下面就部分重要的字段展开进行说明：

resources

服务中一个或多个需要进行权限校验的资源，每个资源对应的描述字段有：

• itemId 资源列表中各个资源的ID，即每个资源都有各自的ID，ID从1开始递增。
• name 资源的名称，只能是小写字母，'-'，'_'的组合，资源名在同一个配置文件中不能重复。
• type 资源的类型，通常为string或path。
• level 资源的层级，多个资源按level从小到大进行排列，同一level的资源位于一个下拉框列表中。
• parent 资源的父类资源，配合level实现多个资源的层级关系。
• isValidLeaf 资源本身作为一个其他资源的parent时，本身是否可以作为叶子结点存在。
• mandatory 是否为必填项。
• lookupSupported 是否支持到具体的服务中进行检索，例如hdfs中的路径，输入"/"后，自动罗列出根目录下的目录和文件。
• recursiveSupported 是否支持递归，通常资源类型为path时使用，其他场景均为false。
• excludesSupported 是否支持排除该资源，类似白名单。
• matcher 资源的值的匹配处理类，通用的资源（资源类型为string）一般使用RangerDefaultResourceMatcher，对于资源类型为path则使用RangerPathResourceMatcher。
• matcherOptions 资源的值匹配方式的选项参数，常用的选项有： wildCard：是否支持通配符； ignoreCase：是否忽略大小写；
• validationRegEx 有效性检查的正则表达式。
• validationMessage 有效性检查的提示信息。
• uiHint 资源填写时的提示信息。
• label 资源在web界面中的显示名称
• description 资源的描述
• accessTypeRestrictions 资源关联的访问动作列表。

对于资源列表，最常见的几种描述形式有：

多个资源分别进行设置，即资源是互斥的

这个时候，多个资源的level配置成一样，这些资源出现在一个下拉框中供选择，例如：

多个资源并行设置，即资源是不互斥的

这个时候，多个资源的level配置按大小进行配置（例如1，2，3或10，15，20，具体大小不重要，只要能区分大小），web界面会从小到大依次排列显示。例如：

多个资源之间有依赖关系

典型的如数据库类型服务中的数据库、表、字段，三者之间有从属关系，这个时候除了多个资源level配置不一样之外，彼此之间还需要配置parent，例如：

这里table和udf的level一样，并且parent为database，因此在一个下拉框中显示。而column的level比table大，并且父类为table，因此只有选择了table才能继续选择column，否则选择了udf就不能继续选择column了。同样，url和database为同一level，选了url后就没有table或udf了。

accessTypes

有了资源，就肯定有对资源的访问动作，accessTypes就定义了需要进行权限控制的访问动作。具体字段包括：

• itemId 同资源中的itemId一样，这里标识访问列表中各个访问类型的ID。
• name 资源访问类型的名称，例如read、write等。
• label 资源访问类型在web界面中显示的信息。

对于访问类型，通常就是进行罗列，比较高级一点的用法是在资源中通过accessTypeRestrictions字段关联一个访问类型列表，例如：

configs

用于连接具体服务的配置信息，例如连接某个hive，可以直接配hive jdbc的url，也可以配置对应的zk地址，从hive注册到zk上的结点信息获取到hive的真实地址。这些具体的配置项就罗列在configs中。

具体配置字段包括：

• itemId 同前面介绍的一样。
• name 配置字段的名称。
• type 配置字段的类型，可选值包括string，password，bool，enum。
• subType 配置字段的字类型 对于父类型为bool的来说，子类型需要补充说明true/false分别对应什么 对于父类型为enum的来说，这里填写字类型的名称，然后在enum中定义该类型
• mandatory 是否为必填项。
• label 在web界面中显示的名称。
• validationRegEx 有效性检查的正则表达式
• validationMessage 有效性检查的提示信息。
• uiHint web界面中填写的提示信息。

一个简单的示例如下图所示：

可以看到，mandatory配置为true后，字段后面都带有"*"，表示必填项；类型为password的配置，填写后以"*"显示，以保护隐私。

enums

对configs中类型为enum进行详细说明。

具体字段包括：

• itemId 字段的ID。
• name 枚举类型的名称，对应configs中subType的值
• elements 枚举值列表，每个枚举值又包括itemId、name、label三个字段
• defaultIndex 默认枚举值，从0开始计算，也就是itemId减1对应的枚举值。

一个简单的示例如下图所示：

服务定义配置文件中比较核心的配置就是上面这几个字段了，至于其他的一些字段，大多可以为空，如果实在有必要配置，可以仿照其他服务进行编写。

讲解完如何编写配置文件，那么接下来就是如何编写ranger admin中的对应的实现类，如何加载该服务配置使其可以在界面中看到对应的模块，并添加对应的服务，和策略的增删查改；以及如何编写插件，嵌入到对应服务中，从ranger拉取策略完成具体的鉴权动作。下篇文章将详细进行说明。

好了，本文就介绍到这里，原创不易，点赞，在看，分享是最好的支持， 谢谢～