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拉取策略完成具体的鉴权动作。下篇文章将详细进行说明。

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