背 景
随着集群变大，使用用户越来越多，原生的Hadoop权限控制已经不能满足用户的需求，社区也围绕着安全做了很多工作，例如原生支持的Kerberos认证和LDAP，Apache Sentry和Apache Ranger等开源项目也在不同程度上做了很多工作，但是各自都有自己的优缺点，所以按照自身需求选择不同的尤为重要。
JDH ACL设计原理
新版的Hadoop权限设计 主要围绕着两方面：用户和组的关系，组和目录之间的关系 ，并且以组作为权限管理的单位，在新版本的Hadoop开放了INodeAttributeProvider类，允许用户去自定义权限检查的逻辑，Jdh ACL的权限控制就是基于该前提去实现用户级别的权限控制。
新的ACL并没有完全的抛弃原生Hadoop的权限检查，而是在其基础上增加了多组的权限检查规则
即使新版本的Hadoop中支持了像Linux一样的ACL(即支持一个文件可以属于多用户和多组的设置，并且可以设置多种权限，权限的设置需要手动递归，不能自动依赖与上层目录的权限)，但是不好的地方在于权限不方便集中的统一管理，而且权限数据会固化到fsimage中等等，所以我们希望找到一种集中管理权限，灵活配置权限的方法，并且以插件的方式实现权限管理的方案，社区中Apache Ranger项目基本符合这种需求，但由于其并不能很好的和公司已有的系统兼容，所以我们参照Ranger的设计思路，按照适合自身的权限需求，设计了自己的一套ACL控制。
像文章开头所说，我们是以组为最小单位做权限控制的，即权限规则的检查也是基于组这个概念，用户是否能够有权限访问这个目录，也就是通过组给关联起来
从上图可以知道，他们之间的映射关系主要可以分为两部分：用户和组的映射关系，组和目录的关系
用户和组的映射关系
对于用户和组的映射关系，hadoop早已经开放接口(GroupMappingServiceProvider)，允许开发者自己实现用户和组的映射关系，LdapGroupsMapping也是基于该接口实现用户和组的映射逻辑，我们自己实现了基于文件可配置的用户和组的映射，添加新的映射关系只需要在统一的权限管理界面UGDAP配置好，触发刷新即可
组和目录的关系
组和目录的映射关系和Ranger一样，采用的是JSON的格式形式存储，对于Ranger来说，多个目录对应多个用户和多个组，其中用户和组可以配置不同的权限，其称为一个Policy，而我们设计的Jdh policy为一个目录对应多个组，不同组分别可以有不同的权限，其中添加了组规则是否递归，是否是排除组的一些概念，以适应自身的需求。
JDH ACL主要一些模块的交互简图如下：
模块的交互简图中PolicyRefresher定时的加载来自UGDAP同步过来的权限策略数据，并重新初始化PolicyEngine和更新PolicyRepository，PolicyRepository会按照一定结构初始化PolicyMaps，以加快权限检查的速度。
权限校验逻辑
对于每一个JDH Policy来说，除了可以配置不同组不同权限之外，还可以配置该目录权限是否递归生效以方便用户权限的配置，另一方面可以配置排除组规则把小部分人加入到排除组中，做到对小部分人关键目录进行隔离。
在每个权限Policy中，都有一个includeMap和excludeMap去存储正常组和排除组规则，权限检查会优先检查excludeMap中的内容，如果符合排除标准，则直接返回，如果排除组检查没有符合排除的标准，则走正常组的权限检查，如果两者都没有符合的标准，则走HDFS原生的权限检查流程。
缓存策略和检查优化
为了尽可能的减少权限路径的查找和路径匹配的时间，我们在PolicyRepository初始化时，对Policy的规则进行了前部分路径的作为查找PolicyMap的key，这样的好处是当一个访问路径/user/bdp/a/b来时，就可以快速的通过key(/user/bdp/a)去找到对应的Policy,如果找不到对应的Policy则默认走Hadoop原生的权限，value则通过目录的深度进行排序，这样也就意味着只要父目录的权限符合要求，就不会检查子目录的权限要求。
对于缓存优化来说，PolicyEngine内部会维护一个固定大小的CacheMap，当进行路径匹配时，可以先从CacheMap里面lookup，看是否已经匹配成功(matchedResourceCache)或不成功的路径(notMatchResourceCache)，如果有这直接返回之前的匹配结果，避免了再次匹配目录，如果没有则加入到缓存中，CacheMap通过Key的访问时间去决定这个Entry是否从CacheMap中移除。