Apache Ranger安全区介绍

本文主要介绍大数据安全管理系统Apache Ranger的安全区Security Zone,根据官方文档人工翻译而来。

介绍

        Apache Ranger为很多Hadoop组件服务和非Hadoop服务提供授权和访问审计服务,比如HDFS、Hive、 HBase、YARN、 Kafka、Storm、 Knox、Atlas、NiFi、Solr等。另外,Apache Ranger可为服务组件提供可伸缩的密钥管理服务,比如为HDFS提供用于数据传输加密的密钥管理服务。并且支持Hive数据仓库的数据脱敏和行过滤策略。

        Apache Ranger可以管理授权策略,交互式查看同一部署环境中跨组件的资源访问情况,从一个集中的管理台界面操作使得管理更简单。同时,Apache Ranger提供丰富的Rest API接口,使得与其它应用的集成更简单。

        在本文中,我们将介绍一种新的特性“安全区”,它将允许分配一个服务中的资源到多个区域中,以便更好地进行安全策略管理。可以使多个管理员基于已赋予管理权限的区域为服务设置安全策略。

例如,让我们考虑两个安全区“财务”和“销售”:

  1. 安全区“财务”包含hive 仓库中名为“财务”的所有内容
  2. 安全区“销售”包含hive 仓库中名为“销售”的所有内容
  3. 用户和组的集合被指定为每个安全区的管理员
  4. 用户只能在他们作为管理员的安全区中设置策略 
  5. 安全区中定义的策略仅适用于区域中的资源
  6. 可以扩展区域以包括来自多个服务(例如HDFS,Hive,HBase,Kafka等)的资源,从而允许安全区管理员为所在组织服务拥有的资源设置策略。

在本文中我们将了解到安全区更详细的信息。

Apache Ranger授权

在我们深入研究安全区之前,让我们先简要了解一下Ranger的授权模型:

- Ranger 管理台, 一个WEB应用,提供UI控制台界面用于创建安全策略和交互地查看访问审计日志

- Ranger授权插件在服务组件中执行资源访问授权,比如HDFS、 Hive、 HBase、YARN、Kafka等服务,并且生成访问审计日志

- Ranger授权插件根据配置通过REST API调用Ranger管理台获得安全策略这些插件还定期从Ranger管理台拉取安全策略的变化信息。

- 每个服务(比如HDFS NameNode、HiveServer2)的安全策略在Ranger 管理台的“service”中定义。 Ranger授权插件根据配置使用指定服务的策略。

安全区

什么是安全区?

1. 安全区由一个或多个服务组件的资源设置组成。 安全区相关的例子如下:

区域: 财务 

服务: prod_hadoop; path=/finance/*, /taxes/*

服务: prod_hive; database=finance

服务: prod_kafka; topic=FIN_*

服务: test_hadoop; path=/finance/*, /taxes/*

区域: 销售

服务: prod_hadoop; path=/sales/*

服务: prod_hive; database=sales

服务: prod_kafka; topic=SALES_*

从上面可以看到,资源可以使用通配符指定 - 比如 FIN_*SALES_*

一个资源不能映射对应多个安全区,Ranger 不允许创建的安全区指定的资源匹配到另一个安全区的资源。

例如,尝试修改如上财务安全区指定HDFS资源路径为/sales/finance/* 是不允许的,因为这与销售安全区指定的HDFS 资源路径 - /sales/*冲突。

2. 用户和组的集合可以指定为每个安全区的管理员。这些用户可以为这个安全区的资源创建、修改、删除安全策略。

3. 用户和组的集合可以被授权查看访问安全区资源的审计日志。其它未授权用户不允许查看该区域资源的访问审计日志。

安全区管理

1. Ranger安全区只能由ROLE_SYS_ADMIN角色的用户创建、修改、删除。

2. 用户只能在拥有管理权限的安全区查看、获取、修改安全策略。

如何用安全区授权?

        当一个Ranger 授权插件授权一个资源访问请求时,首先判断待访问的资源属于哪个安全区。如果资源匹配到一个安全区,只有这个安全区的策略适用于访问授权。如果这个资源未匹配到任何安全区,那么用默认安全区unnamed策略进行访问授权

安全区标签策略

在给定的服务中,每个安全区可以配置从一个标签服务中的具体区域使用标签策略,这使得在资源所属的安全区可以使用不同的基于标签的授权策略。

审计日志

Ranger 授权插件生成审计日志包含访问资源所属的安全区名称,只有在本安全区拥有相应权限的用户可以查看这些审计日志。

APIs 

安全区管理

以下类捕获RangerSecurityZone 对象详情,用于REST APIs创建、获取、修改、删除安全区。Ranger安全区只能由ROLE_SYS_ADMIN角色的用户创建、修改、删除。

package org.apache.ranger.plugin.model;

public class RangerSecurityZone extends RangerBaseModelObject {

private String name;

private List<RangerSecurityZoneService> services;

private List<String> adminUsers;

private List<String> adminUserGroups;

private List<String> auditUsers;

private List<String> auditUserGroups;

}

public static class RangerSecurityZoneService {

private String serviceName;

private List<Map<String, String>> resources;

private String tagService;

private String tagServiceZone;

}

Ranger管理台提供以下 REST APIs 来管理安全区:

@Path("plugins")

@Component

public class SecurityZoneREST {

@POST

@Path("/zones")

public RangerSecurityZone createSecurityZone(RangerSecurityZone securityZone) {

// ...

}

@PUT

@Path("/zones/{name}")

public RangerSecurityZone updateSecurityZone(@PathParam("name") String zoneName,

RangerSecurityZone securityZone) {

// ...

}

@DELETE

@Path("/zones/{name}")

public void deleteSecurityZone(@PathParam("name") String zoneName) {

// ...

}

@GET

@Path("/zones/{name}")

public RangerSecurityZone getSecurityZoneByName(@PathParam("name") String zoneName) {

// ...

}

@GET

@Path("/zones/names")

public List<String> getAllZoneNames() {

// ...

}

}

根据需要将新增更多类似APIs。

策略APIs 

RangerPolicy 

RangerPolicy是用于在REST APIs 中处理策略的类。此类已更新为包含属性“zone”。如下所示:

public class RangerPolicy extends RangerBaseModelObject {

private String service;

private String zone;

private String name;

private Integer policyType;

private Integer policyPriority;

private String description;

}

在引入安全区之前创建的策略此属性设置为null策略如果未定义一个指定安全区,此属性将设置为null。请注意此属性的值是不可改变 的(immutable),即一个策略不能从一个安全区移动到另一个安全区。允许这样做可能会导致意想不到的后果,比如一个安全区中的通配符策略(如*或/*)移动到另一个安全区时将适用于另一组资源

服务REST API 

应更新对策略执行创建/更新/删除/获取操作的所有API,以强制执行安全区管理权限,即应该只允许安全区管理员更改策略和获取策略。

ServicePolicys

ServicePolicys是Ranger管理用来向Ranger授权插件发送策略的类。修改此类以包含与服务相关的安全区信息;这将由授权插件中的Ranger策略引擎用于选择授权访问资源的正确策略集。 

public class ServicePolicies implements java.io.Serializable {

private String serviceName;

private Long serviceId;

private Long policyVersion;

private Date policyUpdateTime;

private List<RangerPolicy> policies;

private RangerServiceDef serviceDef;

private String auditMode = RangerPolicyEngine.AUDIT_DEFAULT;

private TagPolicies tagPolicies;

private List<RangerSecurityZone> zones;

}

审计APIs

VXAccessAudit

VXAccessAudit是REST APIs中用于从Ranger 管理台获取访问审核详细信息的类  该类已更新为包含属性“zone” 访问资源所属的安全区名称,将由Ranger 授权插件填入值。

public class VXAccessAudit extends VXDataObject {

protected int auditType;

protected int accessResult = RangerConstants.ACCESS_RESULT_DENIED;

protected String accessType;

protected String zone;

}

XAuditREST 

获取审计日志的REST API被更新,以确保仅返回来自用户具有管理员权限的安全区的日志。

导出/导入变更 

除了对“service-name(s)”的现有支持外,还应更新导出模块以“zone-name(s)”作为参数,以便仅导出给定安全区中的策略

除了对重命名“service(s)”的现有支持外,还应更新导入模块以启用对“zone(s)”的重命名。

UI变更 (文本模型) 

考虑一个Ranger管理控制台示5个服务,如下所示:

 

以及2个安全区Sales Marketing如下所示:

Zone: Sales

prod_hdfs: /sales

prod_hbase: sales

prod_hive: sales

test_hive: sales

Zone: Marketing

prod_hdfs: /marketing

prod_hbase: marketing

prod_kafka: m_topic1, m_topic2

prod_hive: marketing

test_hive: marketing

Ranger 管理界面将显示以下内容请注意顶部的标签介绍每个安全区一个标签

 

Unzoned”选项卡显示所有服务,这些策略将适用于不属于任何安全区的资源。

 

Sales选项卡包括Sales安全区中含的服务,请注意此处未列出prod_kafka服务。服务中的策略仅适用于Sales安全区中的资源。Marketing 安全区同样如此

与前期版本的兼容

策略 APIs 

用户通过前期api创建/更新/获取/删除策略不知道安全区的概念Ranger 管理台将在默认(unnamed安全区处理API调用。

Grant/Revoke 

用于诸如Hive、HBase支持grant revoke 操作等服务的Ranger授权插件,这些操作在适当的服务中创建/更新策略。随着安全区的引入,应该增强Ranger管理台中的grant/revoke实现,以根据所涉及的资源选择要更新策略的安全区

来源于前期版本的Ranger授权插件

来源于前期版本的Ranger授权插件不知道安全区的概念,将不能识别安全区并评估安全区中的策略。但是它们应该继续使用默认(unnamed)安全区中的策略。

### 如何通过 Ranger 设置 Hive 中仅允许用户使用 COUNT 权限 为了实现通过 Apache Ranger 对 Hive 的权限管理并限制用户只能执行 `COUNT` 操作,可以按照以下方法完成配置: #### 1. 创建 Ranger 策略 在 Ranger Admin 控制台中创建一个新的策略来定义用户的操作范围。具体步骤如下: - 登录到 Ranger Admin UI。 - 导航至 **Hive Service** 下的相关服务名称(例如 `hive_repo`),点击进入其策略页面。 - 添加新策略,在该策略下指定目标数据库表以及应用此策略的具体用户或组。 #### 2. 配置具体的权限选项 当编辑上述新建的策略时,需精确设定哪些 SQL 动作被授权给特定主体(即某位用户)。要让用户仅仅具备运行计数查询的能力,则只勾选 “Select” 和附加条件中的子集功能——这里特别注意的是,“Count” 是作为 select 查询的一部分处理[^1]。 因此,在实际操作过程中应该这样设置: - 勾选 Select 访问级别; - 不授予 Insert, Update 或 Delete 等其他修改型动作的权利; - 利用高级属性进一步细化控制逻辑表达式,确保最终效果限定于统计汇总类语句生效范围内。 #### 3. 测试与验证 完成以上配置之后,可以通过模拟测试确认预期行为是否达成。尝试让受限账户提交各种类型的请求命令看它们能否正常返回结果还是遭到拒绝响应。如果一切顺利的话,除了 count(*) 类似的简单聚合函数外其余任何形式的数据检索都将失败提示无权访问资源的信息。 ```sql -- 正确示例:应成功执行 SELECT COUNT(*) FROM sample_table; -- 错误示例:应当抛出异常因为违反了既定规则 INSERT INTO another_table SELECT * FROM sample_table; UPDATE sample_table SET column_name = 'value' WHERE condition; DELETE FROM sample_table WHERE condition; ``` 此外还需留意可能存在的例外情形比如视图定义内部隐含复杂计算等情况也需要纳入考量范畴之内加以妥善处置以免留下安全隐患漏洞[^2]。 --- ### 注意事项 有时即使设置了严格的 ranger policy ,仍可能出现由于外部因素导致无法完全阻止某些非法活动的发生 。例如当遇到类似下面这样的报错信息时候就需要额外排查是否存在路径冲突等问题影响正常使用体验 : > Unable to create directory /app/hive/tmp/resources/03fbd8c1-5690-429c-aab9-545468255413_resources 这通常表明存在潜在的安全隐患或者是基础环境搭建阶段遗留下来的未解决矛盾点需要逐一核查修正直至彻底消除此类干扰项为止才能保障整个系统的稳定可靠运转状态良好持续提供高质量的服务支持工作不断向前推进发展进步取得更加辉煌灿烂的成绩未来可期充满希望值得期待[^3]. --- ### 数据湖存储架构关联思考 考虑到现代大数据应用场景日益多样化的需求趋势变化特点 , 如果涉及到更大规模更复杂的业务场景分析需求则建议提前规划好整体数据湖存储解决方案框架结构布局安排合理分配各类资源要素充分发挥各自优势特长相互配合协作共同促进提升工作效率效益最大化水平达到理想目标追求极致完美境界享受科技带来的便利快捷美好生活无限美好前景光明远大前程似锦令人向往憧憬不已[^4]. 同时也要记得调整相应的 JDBC URL 参数以匹配新的部署位置和服务端口编号等等细节之处不容忽视忽略任何一个环节都有可能导致全局崩溃瘫痪局面发生所以务必谨慎小心行事每一步都要经过深思熟虑反复推敲论证后再付诸实践行动起来绝不草率从事鲁莽决策造成不可挽回的重大损失后果严重不堪设想难以弥补修复恢复原状几乎不可能实现只有依靠预防为主综合治理相结合的方式方法途径才是长久之计根本出路所在方向明确指引清晰可见成效显著立竿见影事半功倍一举多得互利共赢共享成果造福人类社会大众群体广泛受益受惠无穷尽也[^5]. ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值