Hadoop Ozone Security模块设计概览
前言
任何一个分布式系统，当它的功能实现和设计越趋向于完善的时候，它的安全性就会显得越发的重要。因为一个好用且成熟的系统，依然会存在被恶意者利用安全漏洞攻击的可能性。笔者之前已经聊过些许HDFS安全方面的内容，本文将聊了一个新的系统Hadoop Ozone在这块的设计和实现方式。
分布式系统的安全设计到的模块
在阐述Ozone Security方面内容之前，我们需要了解一个概念：Security。当我们总是频繁聊到一个系统的安全性时，我们到底在聊些什么呢？这个“安全性”3个字中包含了多少内容呢？只是简单的认证机制？简单的权限控制？
以下是笔者暂且想到的：
- 用户，组件的身份认证，就是我们常说的authentication。
- 用户，组件的授权，authorization，在认证之前理应先授权。
- 在授权之前，我们可以有额外简单一点的身份 标识验证，证明”你是你本人“。
- ACL/UGO控制。
- 有关键步骤的audit记录。
OK，下面笔者结合Ozone Security的设计来进行一一阐述。
ACL/UGO控制
一般一个系统在构建之初，最容易和快速做到的关于Security方面的改进就属类似ACL的控制了。它还未设计到具体复杂的加密算法，只要在软件层面进行控制即可。
ACL做的一个主要事情是说，我们可以规定什么用户或组对于资源具有哪些访问权限。ACL其实是对UGO方式的一个扩展。在最开始的时候，我们一般实现到UGO一层就足够了，就是类似于文件系统permission rwx 777那套模式。
UGO的这套控制方式在用户runtime层面可以拒绝它的越权行为，但是也很容易破解。用户只要在登录时用一个假的用户，就可以绕过这层控制。这时候其实不是真正的用户在执行操作，所以这里我们需要又一套证明”你是你自己的“机制。
Kerberos认证机制+PKI公共密钥设施验证
在Ozone中，使用了Kerberos+PKI两种组合使用的认证机制，来作为整体的安全验证。
首先是利用现有Hadoop已经支持的Kerberos认证来作为服务组件的注册准入的验证，说明此服务是合法，可信赖的服务。
接下来与HDFS实现不同的一点在在于，Ozone使用了PKI的方式进行后续的认证过程，而在目前HDFS的实现中，它使用的是共享密钥的加密方式。
那么Ozone采用的PKI的方式和和HDFS的共享密钥的加密方式比，有什么不同点呢：
从加密方式上来讲，共享密钥方式使用的是对称加密方式，服务方和用户使用的是相同的密钥对数据进行加/解密。所以在这种方式下，密钥需要被接收方都妥善保管。而PKI的方式则是一种非对称加密的算法，它有一对公-私密钥，公钥是完全公开的，而私钥是用户需要保管的。数据用公钥进行加密，需要用户自己的私有密钥进行解密。后者在安全性方面，安全性会更高一些。
Ozone在目前是使用了基于X.509证书的PKI方式，相比于对称加密算法，X.509的证书管理是一个更加成熟的领域，并且Java内置库是支持此证书调用的。证书管理下，密钥是私自管理的，所以无须进行密钥的分布式分发和重新生成。在HDFS共享密钥的模式下，NN会定期rotate这个共享密钥，然后重新分发下去。
在X.509证书体系下，SCM会扮演一个CA证书管理机构，证书下发的过程如下：
1)当DataNode在注册时，通过了Kerberos的基本验证后，会向SCM发起一个证书签名请求，简称CSR(certificate signing request)。
2)SCM接受到请求后，会返回DataNode一个带有其签名的证书内容，并且将发出的证书记录下来。
3)DataNode收到证书后，持久化此证书到本地，后续会用此证书进行block访问时的验证。
Ozone中的KSM服务同样会向SCM的CA进行证书的请求，同样会获得一个证书文件。KSM后续会利用这个证书再进行token的签名。此时相当于DataNode和KSM都将SCM作为可信赖的证书机构，然后基于这个CA派发出的证书，进行后续数据的验证。
Audit审计日志
Audit审计记录在分布式系统安全的方面算是比较常见了。这种记录一般用于事后分析比较多，就像一个人的银行流水账单一样。在Audit记录的记录过程中，我们需要确保关键的2点是：1）每行记录包含足够多我们想要的维度信息，2)不能有缺失的操作记录。
引用
[1].https://baike.baidu.com/item/PKI/212376?fr=aladdin
[2].https://issues.apache.org/jira/browse/HDDS-4, Implement security for Hadoop Distributed Storage Layer
