这是彭文华的第132篇原创
我发现呆过的公司基本上会分成两个极端：要么什么都自研，迫不得已才买现成的；要么什么都买买买，迫不得已才自研。市场上现在有很多大数据平台、数据中台的产品都已经把所有功能都集成好了，但是价格可不便宜啊。
比如我们平台建好了，要开放给各业务部门的数据分析师用，但是表太多了，没法管理，这可咋整？大数据平台资源可多呢，HIVE、HBase、Kafka等，每个组件弄一套用户名密码？那还不得废了！所以我们得有一套统一的授权系统来管理才行。
用户和资源
即便是没设计过权限的同学，凭着自己平时使用各种系统的感觉，也能理解必须得有一个表，用来存储所有用户和需要访问资源的对应关系。
用我们最朴素的理解，A用户过来申请访问B表，需要到用户-资源表中扫一下，有权限了，再去执行。这就是权限“鉴权”的逻辑。
但是这么做有个弊端，一旦用户和资源过多，就完蛋了。
这还是6个用户和6个资源，就已经是个灾难了，更别提咱大数据平台动辄几千个表，内部几十上百个人要用，要是加上HIVE、HBase、Kafka等N多组件，那就彻底歇菜了！
RBAC模型
架构感比较好的同学就立刻会想到一个解决方案：在用户和资源之间加一层，起到解耦的作用。
这样就轻松多了，一个权限决定了可以对资源做什么事情，比如增、删、改、查。但是这只是从资源侧解决了部分问题，还有用户侧也少了一些，那就再加一层。
这样就从资源端和用户端都做了一层抽象，也就多了一层解耦。在进行授权、鉴权等权限控制的时候就非常舒服了。进一步我们还可以将角色进行进一步的拆分，比如建个角色分组、分级，再加上组织架构等，这个权限功能就非常丰富了。
这就是传说中的RBAC（基于角色的访问控制Role-Based Access Control）。
至于RBAC的什么概念、什么原则，这里就不赘述了，各位可以去百度一下。意思就是建立一个用户、角色、权限和资源之间对应关系的访问控制模型。
大数据安全组件Ranger
这哥们说了，权限我明白了，那这个安全体系怎么落地呢？
这就要提到跟Apache基金会里与Atlas双贱合并的Ranger了！这个Ranger帮忙做了很多基础工作，向前打通了用户端，向后打通Hive、Base、Kafka、Yarn等组件，关键是他还能与Atlas打通了。而且还提供了统一的权限配置界面，非常友好！
Ranger为各个组件提供一个插件，相当于拦在用户请求的路径上，根据配置的访问策略决定是否应授权这个户请求。
我们可以在Ranger中对一个自营资源（一个或多个文件夹和/或文件）创建安全策略，然后为一组特定的用户和/或组分配特定的权限（例如：读取，写入，执行）。这些策略和权限在策略管理器中，Ranger把这些信息扔到了MySQL里存储。
不过Ranger也有很多不足之处，最让人上头的就是安装了。这玩意各种依赖特别多，而且还有版本限制，真是让人头大。
另外就是支持的组件还是不太够丰富，还有，Ranger好像没完全按照RBAC逻辑去设计，不过对于我们这样已经够用了。
三大安全组件对比
除了Ranger之外，其实还有两个：Kerberos和Sentry。Kerberos比较轻量级，相当于最简单的权限管理。Sentry功能也还行，但是交互性差点意思，连自己的Web UI都没有。
Kerberos轻量级到什么程度呢？就是只能控制你是否能访问Hive，某个表啥的就控制不了啦。不过据说可以集成LDAP，反正我没玩过，也不知道好使不好使。Kerberos实现的逻辑很简单，就是先买票，后上船。它的KDC服务端提供卖票服务，Client到KDC那边买个票，然后再去Server那边验票访问。
Sentry是CDH的标配，在CDH时代，Sentry基本是唯一的安全解决方案。但是升级为CDP之后，就抛弃Sentry，改用Ranger了，所以你看，还是Ranger比较好用吧？要不怎么会换掉呢，是吧？我这边也整（抄）了一个Sentry和Ranger的对比，各位凑合着看吧：
如果你的团队也遇到权限的问题，强烈建议用Ranger。
