0745-什么是Apache Ranger – 3

• 2020 年 2 月 10 日
• 笔记

作者：Eric Lin (林晨辉)， Cloudera高级售后技术支持工程师。毕业于Monash大学计算机科学， Sir John Monash的奖学金获得者。曾就业于数据收集公司如Hitwise（现为Experian的子公司）和Effective Measure，担任高级工程师，负责设计，开发和管理用于采集， 处理和报告网络数据的平台（基于PHP，Java和CDH）。现任职Cloudera， 担任高级售后技术支持工程师，主要擅长解决在CDH生态系统中出现的各种疑难杂症。

在阅读本文前，建议先阅读前面的文章：

《0741-什么是Apache Ranger – 1》

《0742-什么是Apache Ranger – 2》

在本文中我会介绍Ranger的安全区域(Security Zone)功能，其工作方式以及如何在Ranger Admin UI中对其进行配置。以下内容假设你已经通过Ambari或Cloudera Manager7.x安装了Apache Ranger。

首先我们来看看什么是安全区域(Security Zone)

安全区域(Security Zone)在Ranger中提供了将资源策略分成不同区域的功能。这有助于简化安全策略的管理，并允许在针对某些资源进行授权时检查数量有限的策略，因为仅加载和检查包含请求资源的特定区域下的策略。

最重要的是，它还使多个管理员可以根据分配给他们的区域来设置不同的策略。例如，销售管理员只能为分配了HDFS中的/sales目录或Hive中的销售数据库的销售区域(Sales Zone)下的资源设置策略，而开发管理员只能为分配了HDFS中的/dev目录或Hive中的开发数据库的开发区域(Development Zone)下的资源设置策略。该功能在RANGER-2232有进行说明。

添加新的安全区域非常简单，有关详细信息，您可以参考Cloudera的官方文档：Adding a Ranger security zone。这里我不会再做介绍， 但是，要记住的一件事是，只能将一个资源分配给一个安全区域。如果尝试使用已分配给另一个区域的资源来创建新的安全区域，则会被被拒绝。参见下图：

其实你也没有任何理由需要拥有同一个资源去映射到两个不同的安全区域，这也违反了安全区域(Security Zone)的原始设计。

现在，我已经创建了两个安全区域，让我们继续：

在接下来的文章中，我想演示以下内容：

如果某些资源的策略在分配给其他资源的安全区域下已经被定义，你依旧可以在其他安全区域下成功创建这些资源的策略，不过这个策略会被忽略，即不会生效。

以下是我的设置：

• 2个区域，一个是“Sales”，另一个是“Development”
• HDFS目录/sales分配给Sales安全区域
• HDFS目录/dev分配给Development安全区域
• 创建了2个组：sales和dev
• 同时创建了2个用户：user1属于sales组，user2属于dev组

$ groups user1  user1 : user1 sales    $ groups user2  user2 : user2 dev  

如果不设置任何策略，每个用户都不能访问他们的部门数据：

$ sudo -u user1 hdfs dfs -mkdir /sales/user1  mkdir: Permission denied: user=user1, access=WRITE, inode="/sales":hdfs:supergroup:drwxr-xr-x    $ sudo -u user2 hdfs dfs -mkdir /dev/user2  mkdir: Permission denied: user=user2, access=WRITE, inode="/dev":hdfs:supergroup:drwxr-xr-x  

创建Ranger策略也同样很简单，可以参见Cloudera官网的文档：Configure a resource-based policies。我已经创建了2个策略，每个安全区域下有一个用于HDFS。参见下图，Dev HDFS策略在Development Security Zone下，Sales HDFS策略是在Sales Security Zone下：

现在，我可以确认每个用户都可以在自己的部门的HDFS路径下创建目录：

$ sudo -u user1 hdfs dfs -mkdir /sales/user1  $ sudo -u user1 hdfs dfs -ls /sales  Found 1 items  drwxr-xr-x   - user1 supergroup          0 2020-01-26 10:41 /sales/user1    $ sudo -u user2 hdfs dfs -mkdir /dev/user2  $ sudo -u user2 hdfs dfs -ls /dev  Found 1 items  drwxr-xr-x   - user2 supergroup          0 2020-01-26 10:42 /dev/user2  

为简单起见，我没有在实验室中启用Kerberos，因此仅使用“ sudo -u {username}”作为目标用户运行命令，仅用于演示。

现在如果你进入Ranger Admin UI的Audits页面，你可以查看我先前运行命令的审计历史。我过滤了一下只显示user1：

你可以看到第一次尝试创建“/sales/user1”路径时被拒绝。通过上图的最后一栏“Zone Name”，可以发现资源/sales确实位于Sales Zone下，但我们尚未创建策略，因此Ranger没有应用任何授权，而是退回到HDFS ACL，查看上图“Access Enforcer”栏位的值是“hadoop-acl”。

在创建“Sales HDFS”策略以允许sales组下的所有用户都可以访问HDFS的/sales路径后，我们可以看到Ranger接管了授权并授予“ user1”可以创建/sales/user1目录 。我们还可以看到，Ranger记录了在此过程中用于检查的策略，查看上图第一个栏位“Policy ID”的值为58。最后，它还授予了“ user1”执行“ -ls”操作的权限，如上图第一行。

现在，我将尝试创建一个新策略，以允许user1访问HDFS的/dev路径，但仍位于Sales Zone下，并查看其是否生效。参见下图：

我可以确认策略已经保存成功，但是访问还是被拒绝。

$ sudo -u user1 hdfs dfs -mkdir /dev/user1  mkdir: Permission denied: user=user1, access=WRITE, inode="/dev":hdfs:supergroup:drwxr-xr-x  

你可以看到，Ranger尝试检查Development Zone下的策略，但是没有找到任何内容(Policy ID栏的值为空)，因为我们刚刚为此类访问创建的策略实际上在另一个安全区域中，因此它将被忽略，然后Ranger回退到使用hadoop-acl。

因此你如果在做troubleshooting，一件非常重要的事是你需要确保策略是放置在正确的安全区域下。常去Ranger Admin的Audit页面看看Ranger使用了什么策略。

需要注意的一件事是，当根据请求的资源未找到安全区域时，Ranger将使用在安装过程中设置的“Default”区域。这个“Default”区域没有名称，但存在于Ranger数据库的Security Zone表中。

id          | 1  create_time | 2020-01-21 00:51:01.622843  update_time | 2020-01-21 00:51:01.622843  added_by_id | 1  upd_by_id   | 1  version     | 1  name        |  jsondata    |  description | Unzoned zone    id          | 2  create_time | 2020-01-25 00:56:00.276  update_time | 2020-01-25 00:56:00.283  added_by_id | 1  upd_by_id   | 1  version     | 1  name        | Sales  jsondata    | {"name":"Sales","services":{"cm_hdfs":{"resources":[{"path":["/sales"]}]},"cm_hive":{"resources":[{"database":["sales"],"column":["*"],"table":["*"]}]}},"tagServices":["cm_tag"],"adminUsers":["Eric Lin"],"adminUserGroups":[],"auditUsers":["Eric Lin"],"auditUserGroups":[],"description":"For Sales Department","id":-1,"isEnabled":true}  description | For Sales Department  jsondata    | {"name":"Sales","services":{"cm_hdfs":{"resources":[{"path":["/sales"]}]},"cm_hive":{"resources":[{"database":["sales"],"column":["*"],"table":["*"]}]}},"tagServices":["cm_tag"],"adminUsers":["Eric Lin"],"adminUserGroups":[],"auditUsers":["Eric Lin"],"auditUserGroups":[],"description":"For Sales Department","id":-1,"isEnabled":true}  description | For Sales Department    id          | 3  create_time | 2020-01-25 01:02:28.233  update_time | 2020-01-25 01:02:28.234  added_by_id | 1  upd_by_id   | 1  version     | 1  name        | Development  jsondata    | {"name":"Development","services":{"cm_hdfs":{"resources":[{"path":["/dev"]}]},"cm_hive":{"resources":[{"database":["dev"],"column":["*"],"table":["*"]}]}},"tagServices":["cm_tag"],"adminUsers":["Eric Lin"],"adminUserGroups":[],"auditUsers":["admin"],"auditUserGroups":[],"description":"For Development department","id":-1,"isEnabled":true}  description | For Development department  

你可以看到“ x_security_zone”表中存储了一个具有“ id”为1但“name”为空的区域，这张表是Ranger用于在其Web UI中展示安全区域(Security Zone)数据的。未分配给用户创建的安全区域的所有策略将默认为该区域。这意味着对于与任何区域都不匹配的资源，Ranger将检索分配给该默认区域的所有策略以进行授权过程。

原文参考：

https://www.ericlin.me/2020/01/introduction-to-apache-ranger-part-iii/