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