Ranger学习笔记
1 简介
Apache Ranger 是 Hadoop 平台上操作、监控、管理数据安全的集中式安全管理框架。Ranger 的愿景是在 Apache Hadoop 生态系统中提供全面的安全性。
目前,Apache Ranger 支持以下 Apache 项目的细粒度授权和审计:
(1)Apache Hadoop
(2)Apache Hive
(3)Apache HBase
(4)Apache Storm
(5)Apache Knox
(6)Apache Solr
(7)Apache Kafka
(8)YARN等等
Ranger 通过访问控制策略提供了一套标准的授权方法,改变了Hadoop上各个组件各自为政分散管理权限的现状。作为标准,Ranger提供了集中式的组件,用于审计用户的访问行为和管理组件间的安全交互行为。
Ranger核心特性:
(1) 集中安全管理,在中央UI或使用REST API管理所有与安全相关的任务。
(2) 精细授权,使用Hadoop组件/工具执行特定动作或操作,并通过集中管理工具进行管理。
(3) 标准化所支持Hadoop组件的授权方法。
(4) 增强了对不同授权方法的支持 - 基于角色的访问控制,基于属性的访问控制,基于Tag的访问控制(需结合Atlas)等
(5) 在所支持的Hadoop组件中集中审计用户访问和管理操作(与安全相关)
(6) 支持和kerberos的集成
2 权限模型
访问权限定义了”用户-资源-权限“这三者间的关系,Ranger基于策略来抽象这种关系,进而延伸出自己的权限模型。”用户-资源-权限”的含义详解:
- 用户:由User或Group来表达,User代表访问资源的用户,Group代表用户所属的用户组。
- 资源:由Resource来表达,不同的组件对应的业务资源是不一样的,比如HDFS的File Path,HBase的Table。
- 权限:由(AllowACL, DenyACL)来表达,类似白名单和黑名单机制,AllowACL用来描述允许访问的情况,DenyACL用来描述拒绝访问的情况。不同的组件对应的权限也是不一样的。
Ranger中的访问权限模型可以用下面的表达式来描述,从而抽象出了”用户-资源-权限“这三者间的关系:
Service = List<Policy>
Policy = List<Resource> + AllowACL + DenyACL
AllowACL = List<AccessItem> allow + List<AccssItem> allowException
DenyACL = List<AccessItem> deny + List<AccssItem> denyException
AccessItem = List<User/Group> + List<AccessType>
下表列出了Ranger支持的所有系统的模型实体枚举值:
Service | Resource | Access Type |
---|---|---|
HDFS | Path | Read,Write,Execute |
HBase | Table,Column-family,Column | Read,Write,Create,Admin |
Hive | Database,Table,UDF,Column,URL | Select,Update,Create,Drop,Alter,Index,Lock,Write,Read,ALL |
Sqoop | Connector,Link,Job | READ,WRITE |
Storm | Topology | Submit Topology,File Upload,File Download,Kill Topology,Rebalance,Activate,Deactivate,Get Topology Conf, Get Topology,Get User Topology,Get Topology Info,Upload New Credential |
Solr | Collection | Query,Update,Others,Solr Admin |
Kafka | Topic | Publish,Consume,Configure,Describe,Create,Delete,Kafka Admin |
Knox | Topology,Service | Allow |
Kylin | Project | QUERY,OPERATION,MANAGEMENT,ADMIN |
YARN | Queue | submit-app,admin-queue |
Atlas | Type Catagory,Type Name,Entity Type,Entity Classification,Entity ID,Atlas Service | Create Type,UpdateType,Delete Type,Read Entity,Create Entity,Update Entity,Delete Entity,Read Classification,Add Classification,Update Classification,Remove Classification,Admin Export,Admin Import |
Nifi | NiFi Resource | Read,Write |
在访问权限模型中,AllowACL和DenyACL需要分别对应两组AccessItem。下面由具体使用场景进行说明:
以AllowACL为例,假定我们要将资源授权给一个用户组G1,但是用户组里某个用户U1除外,这时只要增加一条包含G1的AccessItem到AllowACL_allow,同时增加一条包含U1的AccessItem到AllowACL_allowException即可。
类似的原因可反推到DenyACL。
既然现在一条Policy有(allow, allowException, deny, denyException)这么四组AccessItem,那么判断用户最终权限的决策过程是怎样的?
总体来说,这四组AccessItem的作用优先级由高到低依次是:
denyException > deny > allowException > allow
访问决策树可以用以下流程图来描述:
总结一下就是黑名单优先级高于白名单,黑名单排除优先级高于黑名单,白名单排除优先级高于白名单。
决策下放:如果没有policy能决策访问,一般情况是认为没有权限拒绝访问,然而Ranger还可以选择将决策下放给系统自身的访问控制层,比如HDFS的ACL,这个和每个Ranger插件以及应用系统自己的实现有关。
3 总体架构
Ranger主要由以下三个组件构成:
- RangerAdmin: 以RESTFUL形式提供策略的增删改查接口,同时内置一个Web管理页面。
- AgentPlugin: 嵌入到各系统执行流程中,定期从RangerAdmin拉取策略,根据策略执行访问决策树,并且记录访问审计。插件的实现原理将在后文详细介绍。
- UserSync: 定期从LDAP/Unix/File中加载用户,上报给RangerAdmin。
Ranger的其他架构简要说明:
- KMS: Hadoop透明加密,Hadoop Key Management Server(KMS)是一个基于HadoopKeyProvider API编写的密钥管理服务器。RangerKMS就是对KMS的策略管理和秘钥管理,使用keyadmin用户登陆。
- TAG: 基于标签的权限管理,当一个用户的请求涉及到多个应用系统中的多个资源的权限时,可以通过只配置这些资源的tag方便快速的授权。
4 系统插件
统插件主要负责三件事:
- 定期从RangerAdmin拉取策略
- 根据策略执行访问决策树
- 实时记录访问审计
以上执行逻辑是通用的,可由所有系统插件引用,因此剩下的问题是如何把这些逻辑嵌入到各个系统的访问决策流程中去。
实现可扩展接口:多数的系统在实现时都有考虑功能扩展性的问题,一般会为核心的模块暴露出可扩展的接口,访问控制模块也不例外。Ranger通过实现访问控制接口,将自己的逻辑嵌入各个系统。
下表列出了Ranger插件对所有支持的系统的扩展接口:
Service | Extensible Interface | Ranger Implement Class |
---|---|---|
HDFS | org.apache.hadoop.hdfs.server.namenode.INodeAttributeProvider | org.apache.ranger.authorization.hadoop.RangerHdfsAuthorizer |
HBase | org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos.AccessControlService.Interface | org.apache.ranger.authorization.hbase.RangerAuthorizationCoprocessor |
Hive | org.apache.hadoop.hive.ql.security.authorization.plugin.HiveAuthorizerFactory | org.apache.ranger.authorization.hive.authorizer.RangerHiveAuthorizerFactory |
Sqoop | org.apache.sqoop.security.AuthorizationValidator | org.apache.ranger.authorization.sqoop.authorizer.RangerSqoopAuthorizer |
Storm | org.apache.storm.security.auth.IAuthorizer | org.apache.ranger.authorization.storm.authorizer.RangerStormAuthorizer |
Solr | org.apache.solr.security.AuthorizationPlugin | org.apache.ranger.authorization.solr.authorizer.RangerSolrAuthorizer |
Kafka | kafka.security.auth.Authorizer | org.apache.ranger.authorization.kafka.authorizer.RangerKafkaAuthorizer |
Knox | org.apache.knox.gateway.deploy.ProviderDeploymentContributorBase | org.apache.ranger.authorization.knox.deploy.RangerPDPKnoxDeploymentContributor |
Kylin | org.apache.kylin.rest.security.ExternalAclProvider | org.apache.ranger.authorization.kylin.authorizer.RangerKylinAuthorizer |
YARN | org.apache.hadoop.yarn.security.YarnAuthorizationProvider | org.apache.ranger.authorization.yarn.authorizer.RangerYarnAuthorizer |
Atlas | org.apache.atlas.authorize.AtlasAuthorizer | org.apache.ranger.authorization.atlas.authorizer.RangerAtlasAuthorizer |
Nifi | NA | NA |
各个系统插件安装节点:
Service | Install Node |
---|---|
HDFS | Name Node |
HBase | Master,Regional Server |
Hive | HiveServer2 |
Sqoop | ALL/Stand-alone |
Storm | ALL/Cluster |
Solr | ALL/Cluster |
Kafka | ALL/Cluster |
Knox | Knox gateway |
Kylin | ALL/Stand-alone |
YARN | Resource Manager |
Atlas | ALL/Stand-alone |
Nifi | NA |
系统插件拉取策略:
主动到RangerAdmin拉取策略,而非RangerAdmin把策略下发给各个插件,策略有变化时,拉取新的策略更新内存中鉴权引擎,同时保存一份备份文件在本地,RangerAdmin挂掉后,组件也重启时,可以使用本地的备份继续鉴权。删除RangerAdmin上面的service,会使插件鉴权不可用。
系统插件性能考虑:
关闭策略中的audit审计日志
插件鉴权引擎定时对策略排序,优先匹配高命中的策略
权限管理流程,以Sqoop2插件的权限控制为例:1. RangerAdmin创建服务Service
- RangerAdmin创建策略Policy
- SqoopPlugin插件拉取策略
- SqoopPlugin对用户访问请求鉴权:show connector
- SqoopPlugin插件记录审计日志Audit
- RangerAdmin查看审计日志Audit