如何实现hadoop的安全机制
目录
hadoop安全设计
hadoop安全机制基于kerberos实现，支持hadoop各组件间的认证、用户认证、数据传输安全、作业管理认证等功能，hadoop组件众多，每个组件在基于kerberos认证时都有各自的考虑，因此这节的内容会逐渐完善：
- hdfs安全认证
- client与namenode间认证。client、namenode间认证通过kerberos方式认证，与kerberos认证方式没有太多区别。
- 代理ticket。client在认证完成后与namenode交互通过临时ticket交互，但hdfs却没有用kerberos管理临时ticket，而是自己管理临时ticket，即namenode自己维护一个临时ticket列表，不会每次都向kerberos获取。这样处理原因是mr作业并发较大时每次都向KDC发起认证请求可能造成KDC成为性能瓶颈，虽然可以使用KDC管理临时ticket，但是java的GSS-API库原生不支持这个功能，如果通过native api支持可能会有移植性问题，最终还是由namenode支持。代理ticket可以被mr task使用，也可以被app master续约，总之一旦完成认证，后续所有的文件请求都基于代理ticket。
- 基于代理ticket认证。使用代理ticket认证时加密算法使用sha1以ticket与token id计算出用于验证的hashcode，并用这个hashcode为key用md5认证协议校验彼此的认证信息。
- 数据块授权。namenode管理着文件权限，但datanode却没有块的权限信息，client向datanode发起块操作请求时也需要带上块操作权限认证。这部分认证做了简化处理，namenode和所有的datanode都使用同一个key加密数据，namenode定期更新加密key并将更新的key通过心跳传给datanode，块加密key不会在永久存储中，只在内存中存储。client在请求数据时namenode会将块token传给client，client向datanode请求块数据时以这个token进行验证。
- 数据传输加密。在开启kerberos安全模式下，datanode也支持数据传输安全，通过https实现数据传输安全性支持。
- 代理ticket的问题。考虑到安全性问题代理ticket有最长使用期限的限制，一旦过了这个期限代理ticket也无法被续约，hdfs默认设置这个时间为7天，他们考虑作业最行运行时间不会超过7天。假设对于流式作业却不适用，流式作业都是long running的作业，需要自己处理这种情况。在spark streaming中driver会启动后台线程定期检查代理ticket的有效性，一旦将要失效再次向namenode发起认证请求一个新的临时ticket并写到hdfs上，worker会定期扫描hdfs上的认证文件，一旦发现有变化就重新加载。
- yarn安全认证
- 作业管理、操作认证。采用标准的kerberos认证，由于这些操作相对不太频繁，并没有采用代理ticket方式。
- 队列管理。队列ACL控制由super user管理。
- 作业运行。在安全模式下yarn采用LinuxContainerExecutor启动进程用户作业，LinuxContainerExecutor会设置进程的权限、目录操作权限、资源限制等并以用户身份启动进程。为了保证数据及执行的安全性，作业运行的用户也会加限制，要求uid必须大于每个值且不能是系统若干账户，尤其不能是super user。
- cache管理。还未看在安全模式下yarn是如何支持认证的。
- mr安全认证
- 作业运行时hdfs代理ticket管理。作业运行时需要有人对代理ticket续约，在作业运行完成后删除相应的ticket，如果每个task做这个操作就有点浪费且安全性也不高，因此这个功能由App Master完成，App Master定期续约代理ticket。
- task如何使用代理ticket。在提交作业时代理ticket被写入hdfs某个目录中，task在运行时会读取ticket信息并使用。
- shuffle安全性。为了保证shuffle数据安全性，shuffle操作也需要认证，为了减少多次交互带来的性能影响，shuffle认证是一次完成的，在请求数据就带上计算的认证信息，而其它认证都需要多次认证。
- web ui
web ui也是大家经常使用的组件，常用的浏览器都可以设置为支持kerberos认证，不需要太多开发。
- 其它：待补充