月度归档： 2012 年 12 月

发布于

HADOOP 的安全性

背景

当Hadoop在2004年开始开发的时候，对如何创建一个安全的分布式计算式环境上没有考虑，Hadoop框架对用户及服务的验证和授权严重不足，用户可以仿冒任意一个HDFS和mapreduce上的用户，恶意的代码可以以任何一个用户提交到Job tracker，尽管在版本0.16以后， HDFS增加了文件和目录的权限，但由于用户无需认证，HDFS的权限控制也极其容易绕过，允许一个用户伪装成任意一个用户，同时计算框架也没有进行双向验证，一个恶意的网络用户可以模拟一个正常的集群服务加入到hadoop集群，去接受JobTracker, Namenode的任务指派。

此时HADOOP要安全只能靠严格的的网络隔离，能访问hadoop集群的用户都是完全可信赖的用户。

到了2009年，关于hadoop安全性的讨论已经接近白热化了，安全被作为一个高优先级的问题摆了出来，Hadoop 2010年的开发计划就包含的用户与服务的双向认证，并且对终端用户透明。具体可参见【HADOOP-4487 Security features for Hadoop7】

安全设计时有以下6大目标：

1.2 Requirements

1. Users are only allowed to access HDFS files that they have permission to access.

2. Users are only allowed to access or modify their own MapReduce jobs.

3. User to service mutual authentication to prevent unauthorized NameNodes, DataNodes, JobTrackers, or TaskTrackers.

4. Service to service mutual authentication to prevent unauthorized services from joining a cluster’s HDFS or MapReduce service.

5. The acquisition and use of Kerberos credentials will be transparent to the user and applications, provided that the operating system acquired a Kerberos Ticket Granting Tickets (TGT) for the user at login.

6. The degradation of GridMix performance should be no more than 3%.

为了达到这目标，开发者决定使用kerberos进行认证。选择kerberos而非SSL基于以下理由：

1. kerberos使用对称密钥可以达到更高的性能，比使用公钥的SSL更快。

2. 简化了用户管理。例如，取消一个用户只需要简单的将用户从KDC里面删除即可，而如果使用SSL就需要生成证书注销列表(CRL) 并分发到所有服务器。

Hadoop的安全设计有以下七大假设

1.For backwards compatibility and single-user clusters, it will be possible to configure the cluster with the current style of security.

2. Hadoop itself does not issue user credentials or create accounts for users. Hadoop depends on external user credentials (e.g. OS login, Kerberos credentials, etc). Users are expected to acquire those credentials from Kerberos at operating system login. Hadoop services should also be configured with suitable credentials depending on the cluster setup to authenticate with each other.

3. Each cluster is set up and configured independently. To access multiple clusters, a client needs to authenticate to each cluster separately. However, a single sign on that acquires a Kerberos ticket will work on all appropriate clusters.

4. Users will not have access to root accounts on the cluster or on the machines that are used to launch jobs.

5. HDFS and MapReduce communication will not travel on untrusted networks.

6. A Hadoop job will run no longer than 7 days (configurable) on a MapReduce cluster or accessing HDFS from the job will fail.

7. Kerberos tickets will not be stored in MapReduce jobs and will not be available to the job’s tasks. Access to HDFS will be authorized via delegation tokens as explained in section 4.1.

以上七个假设基本就是Hadoop安全设计的七大安全缺陷。了解以后也就可以更有针对的对安全问题进行防范。

为了保证开发进度以及保证向后兼容，开发者在设计过程中对安全设计进行了部分妥协，首先新的设计要求终端用户不能在集群中的任何机器上拥有高权限的管理帐户，例如root。如果终端用户对集群中的机器拥有root权限，他就可以发现 Delegation Tokens, Job Tokens, Block Access Tokens或者symmetric encryption keys ，进而颠覆整个系统的安全保证。同时在开发过程中决定保证安全的新功能对于集群性能的影响不大于3%，这导致的开发者倾向使用对称加密算法，并且对网络传输不加密。

 部署hadoop kerberos方案后的安全顾虑

在hadoop新的安全设计中使用的 “threat model” 引起了一些新的安全性上的考虑。首先是SASL (Simple Authenticationand Security Layer)默认提供的安全保护，广泛分发的对称密钥。二是因为强调性能以及加密耗费资源的前提假设，hadoop使用了非常低的默认SASL  QoP （Quality of Protection），尽管SASL over kerberos其实可以做到更好。但hadoop的默认QoP只是进行认证，对于网络通信的完整性以及加密功能并未提供。Hadoop的PRC通信就可以被窃听及修改。同时新的Hadoop 安全设计依赖于HMAC-SHA1 这个对称密钥加密算法。因为Block Access Token 需要，HMAC-SHA1的对称密钥需要分发到Namenode以及所有的datanode机器，这意味着成百上千台的服务器。如果密钥被攻击者发现那么所有datanode上的数据都极其容易受到攻击。只要知道DATAID，攻击者就可以仿冒一个Block Access Token ，进而将hadoop的安全行降低到上一个版本的水平。而且HDFS Proxy使用的是基于IP的认证。一旦获得了HDFS Proxy Server的访问权，就可以读取HDFS Proxy Server 所被授权的所有数据。

二.CDH 4 mrv1 与kerberos集成

测试使用版本如下：

kerberos server 版本:krb5-server-1.9-33.el6.x86_64

Hadoop 版本: CDH4 W/ MRV1

操作系统版本：Redhat Enterprise Linux 6 update 3 64bit

JAVA版本：jdk-6u35-linux-x64

 

服务器名 IP 用途
rhel227.hadoop.hylandtec.com 172.16.130.227 Kerberos 服务器
rhel63.hadoop.hylandtec.com 172.16.130.234 Hadoop服务器

两台服务器均已经在DNS server上配置好正向及反向解析。hadoop.hylandtec.com 指向kerberos服务器。

安装kerberos服务器

作为测试，仅使用kerberos作为认证服务器，安装系统盘中的krb5-server-1.9-33.el6.x86_64.rpm，krb5-libs-1.9-33.el6.x86_64, krb5-workstation-1.9-33.el6.x86_64

kerberos realm 我们规划为HADOOP.HYLANDTEC.COM，以下配置中注意realm 必须为大写！

编辑/etc/krb5.conf

[logging]

default = FILE:/var/log/krb5libs.log

kdc = FILE:/var/log/krb5kdc.log

admin_server = FILE:/var/log/kadmind.log

[libdefaults]

default_realm = HADOOP.HYLANDTEC.COM

dns_lookup_realm = false

dns_lookup_kdc = false

ticket_lifetime = 24h

renew_lifetime = 7d

forwardable = true

[realms]

HADOOP.HYLANDTEC.COM = {

kdc = rhel227.hadoop.hylandtec.com:88

admin_server = rhel227.hadoop.hylandtec.com:749

default_domain = HADOOP.HYLANDTEC.COM  }

[domain_realm]

.hadoop.hylandtec.com = HADOOP.HYLANDTEC.COM

hadoop.hylandtec.com = HADOOP.HYLANDTEC.COM

[kdc]

profile = /var/kerberos/krb5kdc/kdc.conf

以root用户执行，按照提数输入master key：

 kdb5_util create -s

编辑/var/kerberos/krb5kdc/kdc.conf 文件。设置如下：

[kdcdefaults]

kdc_ports = 88

kdc_tcp_ports = 88

[realms]

HADOOP.HYLANDTEC.COM = {

#master_key_type = aes256-cts

max_renewable_life = 7d

max_life = 2d 0h 0m 0s

default_principal_flags = +renewable

krbMaxTicketLife = 172800

krbMaxRenewableAge = 604800

acl_file = /var/kerberos/krb5kdc/kadm5.acl

dict_file = /usr/share/dict/words

admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab

supported_enctypes =  aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal

}

编辑/var/kerberos/krb5kdc/kadm5.acl 文件，配置如下：

*/[email protected]    *

执行以下命令，新增root用户

kadmin.local  -q “addprinc root/[email protected]“

配置完成后执行以下命令启动kerberos服务：

service krb5kdc start

service kadmin start

经配置好的/etc/krb5.conf 文件分发至hadoop各台机器即可。kerberos服务器安装完成。

 

HADOOP kerberos 配置

按照官方文档配置即可，没有问题。

https://ccp.cloudera.com/display/CDH4DOC/Configuring+Hadoop+Security+in+CDH4

有时候kerberos出错的提示很不明朗的时候。设置如下环境变量很有帮助：

export HADOOP_OPTS=”-Dsun.security.krb5.debug=true”

参考资料:

【1】 Hadoop Securit Design  

【2】Hadoop Security Design Just Add Kerberos? Really?

【3】Hadoop Security Overview

【4】Hadoop Kerberos安全机制介绍

【5】Configuring Hadoop Security in CDH4

 

RFC 3961

Kerberos ETypes Kerberos加密类型代码

 

	encryption type                etype      section or comment
      -----------------------------------------------------------------
      des-cbc-crc                        1             6.2.3
      des-cbc-md4                        2             6.2.2
      des-cbc-md5                        3             6.2.1
      [reserved]                         4
      des3-cbc-md5                       5
      [reserved]                         6
      des3-cbc-sha1                      7
      dsaWithSHA1-CmsOID                 9           (pkinit)
      md5WithRSAEncryption-CmsOID       10           (pkinit)
      sha1WithRSAEncryption-CmsOID      11           (pkinit)
      rc2CBC-EnvOID                     12           (pkinit)
      rsaEncryption-EnvOID              13   (pkinit from PKCS#1 v1.5)
      rsaES-OAEP-ENV-OID                14   (pkinit from PKCS#1 v2.0)
      des-ede3-cbc-Env-OID              15           (pkinit)
      des3-cbc-sha1-kd                  16              6.3
      aes128-cts-hmac-sha1-96           17          [KRB5-AES]
      aes256-cts-hmac-sha1-96           18          [KRB5-AES]
      rc4-hmac                          23          (Microsoft)
      rc4-hmac-exp                      24          (Microsoft)
      subkey-keymaterial                65     (opaque; PacketCable)