Hadoop-第八周

最新推荐文章于 2022-11-25 15:51:51 发布

fightingD&W

最新推荐文章于 2022-11-25 15:51:51 发布

阅读量213

点赞数

分类专栏： hadoop 文章标签： hadoop

本文链接：https://blog.csdn.net/weixin_44588186/article/details/116143480

版权

hadoop 专栏收录该内容

9 篇文章 0 订阅

订阅专栏

一、熟悉Kerberos认证原理

1.1 基本原理

Kerberos认证主要分为两个部分:允许进行后续验证的初始验证以及所有后续验证自身。
具体怎么理解呢？我们可以将生活中的护照申请比喻成第一阶段的初始验证，而我们去办理签证比喻成第二阶段的验证。我们如果要去办理外国签证，我们需要先去办理护照，而一旦护照办理成功了，我们就可以直接去办理签证了，而我们的护照会有时间限制，同样我们的初始验证阶段也可以设置失效日期，一旦初始验证阶段日期失效，则需要重新申请验证方可进行第二阶段的后续验证

1.2 允许进行后续验证的初始验证

由图可知，通过第一阶段，客户机会从KDC（Key Distribution Center–密钥分发中心）获取允许其获取服务票证的TGT（Ticket-Granting-Ticket–也就是后续所说的Ticket票证），

同时开始了Kerberos会话。

1.3 后续Kerberos验证

由上图可知，这个阶段会真正的进行kerberos服务的验证了，客户机将第一阶段获取到的TGT发送给KDC，同时告诉KDC他想获取那个服务的票证，

KDC会验证客户机发送的TGT，如果该TGT是合法的，则会将服务器票证发送给客户机，然后客户机使用KDC发回的服务器票证向服务器进行验证，

同时服务器也发送客户端发过来的TGT向KDC进行验证，如果验证成功，则会允许客户机进行登录并操作。对客户机的TGT发将此处的服务器可以是Kerberos的不同服务了，如ftp，telnet等。

注意：在上述的原理讲述中，我们会涉及两个不同的TGT，一个TGT是允许获取后续服务的TGT，另一个是用于登录不同服务器时用于验证的TGT。

只要允许获取后续服务的TGT没失效，则可直接进行第二阶段获取用于登录服务器的验证TGT。

1.4 相关术语

1.5 票证生命周期

1.5.1基本概念

Kerberos ticket 有两种生命周期，ticket timelife (票据生命周期) 和 renewable lifetime (可再生周期)。

当 ticket lifetime 结束时，该 ticket 将不再可用。
如果 renewable lifetime > ticket lifetime ，那么在票据生命周期内都可以其进行续期，直到达到可再生周期的上限。
当时间达到 renewable lifetime 后，ticket lifetime结束后将不能继续续期，续期时将会报错 KDC can't fulfill requested option while renewing credentials，之后需要重新申请新的 ticket。
在安全性方面，与使用较长的生命周期的票据相比，可再生票据的优点是KDC可以拒绝续期请求(例如，如果发现帐户被破坏，并且可再生票据可能在攻击者手中)。
可再生周期和 keytabs 无关，如果你没有修改 key 和 principal 的关系，keytabs 将不用关心。
例如:

ticket_lifetime = 1d
renew_lifetime = 7d
在登陆后的24h内可以对ticket进行续期，直到第一次登陆的7天后将不再允许续期。
在24h内如果没有续期，将无法续期。
对 ticket 进行一次续期后，ticket_lifetime 将恢复到24h。

1.5.2 影响生命周期的因素

1 、命令行

kinit -l lifetime –
如果 -l 参数没有设置，会使用机器上 /etc/krb5.conf 配置的 ticket_lifetime ，但是如果指定的时间长度大于 max_life，则使用 max_life
kinit -s start_time – start_time 表示证书延时生效的时间
kinit -r renewable_life – 更新 renewable_lifetime 时间

2、客户端配置项 /etc/krb5.conf

renew_lifetime – 设置可续约的时长，默认为0。
ticket_lifetime – 初始化 ticket 的生命周期，默认是 1day。

3、服务端配置项 /var/kerberos/krb5kdc/kdc.conf

max_life – ticket 的默认生命周期，默认为 24h
max_renewable_life – ticket 允许被 renew 的最长时期，默认为 0

tip1: 在创建一个新的 ticket 时，ticket_lifetime 和 renewable_lifetime 由上述三种参数的最小值决定。

tip2: 如果你的 KDC 没有设置 max_renewable_life（max_renewable_life=0），那么在客户端 ticket_lifetime 结束时就会获取一个新的 ticket。

tip3: 如果 ticket 存在默认的缓存中，可以用 klist 检查 ticket 的生命周期或是 kinit -R 更新 ticket 的生命周期。

tip4: 添加一个新的 principal 时，默认使用kdc.conf中的生命周期。如果在新建 principal 后想要对最大生命周期进行修改，可以通过 modprinc -maxrenewlife/-maxlife 进行修改，例如 modprinc -maxlife 00:15:00 test/host1@TONGDUN.COM

add_one_principal (argv[i],
                 opt->random_key_flag,
                 opt->random_password_flag,
                 opt->use_defaults_flag,
                 opt->verbose_flag,
                 opt->password_string,
                 kdp,
                 opt->max_ticket_life_string,
                 opt->max_renewable_life_string,
                 opt->attributes_string,
                 opt->expiration_time_string,
                 opt->pw_expiration_time_string);

kerberos认证原理

二、熟悉基于Kerberos的Hadoop安全认证机制

2.1 Hadoop 安全问题

2.1.1 用户到服务器的认证问题

用户可以伪装成其他用户***到一个HDFS 或者MapReduce集群上。

Datanode对读入输出并没有认证。导致如果一些客户端如果知道block的ID，就可以任意的访问DataNode上block的数据

可以任意的杀死或更改用户的jobs，可以更改JobTracker的工作状态

2.1.2 服务器到服务器的认证问题

用户可以伪装成datanode ,tasktracker，去接受JobTracker, Namenode的任务指派。

2.1.3 Kerberos能解决的Hadoop安全认证问题

kerberos实现的是机器级别的安全认证，也就是前面提到的服务到服务的认证问题。事先对集群中确定的机器由管理员手动添加到kerberos数据库中，在KDC上分别产生主机与各个节点的keytab(包含了host和对应节点的名字，还有他们之间的**)，并将这些keytab分发到对应的节点上。通过这些keytab文件，节点可以从KDC上获得与目标节点通信的**，进而被目标节点所认证，提供相应的服务，防止了被冒充的可能性。

由于kerberos对集群里的所有机器都分发了keytab，相互之间使用**进行通信，确保不会冒充服务器的情况。集群中的机器就是它们所宣称的，是可靠的。

防止了用户伪装成Datanode，Tasktracker，去接受JobTracker，Namenode的任务指派。

Kerberos对可信任的客户端提供认证，确保他们可以执行作业的相关操作。防止用户恶意冒充client提交作业的情况。

用户无法伪装成其他用户***到一个HDFS 或者MapReduce集群上

用户即使知道datanode的相关信息，也无法读取HDFS上的数据

用户无法发送对于作业的操作到JobTracker上

无法控制用户提交作业的操作。不能够实现限制用户提交作业的权限。不能控制哪些用户可以提交该类型的作业，哪些用户不能提交该类型的作业。这些由ACL模块控制（参考）