文档章节

从kinit到kerberos安全机制

sherlockyb
 sherlockyb
发布于 2017/06/04 15:32
字数 3756
阅读 213
收藏 0

  最近老在项目的shell脚本中看到kinit这个东西,完整的命令是

   kinit -k -t ./conf/kerberos.keytab sherlocky/admin@EXAMPLE.COM

  查阅一番资料后了解到,之所以有这个命令,是由于该shell脚本接下来会访问Hadoop集群,从上面拉取文件做一些处理任务,并将结果存到Hadoop集群上,那么该命令的作用就是进行身份验证(Authentication),确保Hadoop集群资源的安全。这里就牵扯到kerberos协议,本文接下来将对此一一阐述。

一、kinit命令

  Kinit命令用于获取和缓存principal(当前主体)初始的票据授予票据(TGT),此票据用于Kerberos系统进行身份安全验证,实际上它是MIT在版权许可的条件下为kerberos协议所研发的免费实现工具MIT Kerberos(当前最新版本为krb5-1.15.1)的一部分,相关的配套命令还有klistkdestorykpasswdkrb5-config等等,基本用法如下:

kinit [-V][-l lifetime] [-s start_time][-r renewable_life][-p | -P][-f | -F][-a][-A][-C][-E][-v][-R][-k [-t keytab_file]][-c cache_name][-n][-S service_name][-I input_ccache][-T armor_ccache][-X attribute[=value]][principal]

  各选项具体含义都不做介绍了,可参考官网,较常用的方式就如前言所示,根据指定的事先生成的kerberos.keytab文件为指定个体进行验证。验证通过后,就可以像平常一样进行Hadoop系列操作。那么它是如何进行验证的呢?其中的过程和原理又是怎样的?下面要介绍的kerberos协议细节将会回答你的疑惑。

二、Kerberos协议

  Kerberos(具体可参考RFC1510)是一种网络身份验证的协议(注意它只包括验证环节,不负责授权,关于这两者后面会有介绍区分),用户只需输入一次身份验证信息,就可凭借此验证获得的票据授予票据(ticket-granting ticket)访问多个接入Kerberos的服务,即SSO(Single Sign On,单点登录)。

1.基本概念

  • Principal:安全个体,具有唯一命名的客户端或服务器。命名规则:主名称+实例+领域,如本文开头中的sherlocky/admin@EXAMPLE.COM
  • Ticket:票据,一条包含客户端标识信息、会话密钥和时间戳的记录,客户端用它来向目标服务器认证自己
  • Session key:会话密钥,指两个安全个体之间使用的临时加密秘钥,其时效性取决于单点登录的会话时间长短
  • AS:认证服务器(Authentication Server),KDC的一部分。通常会维护一个包含安全个体及其秘钥的数据库,用于身份认证
  • SS:特定服务的提供端(Service Server)
  • TGS:许可证服务器(Ticket Granting Server),KDC的一部分,根据客户端传来的TGT发放访问对应服务的票据
  • TGT:票据授予票据(Ticket Granting Ticket),包含客户端ID、客户端网络地址、票据有效期以及client/TGS会话密钥
  • KDC:Key分发中心(key distribution center),是一个提供票据(tickets)和临时会话密钥(session keys)的网络服务。KDC服务作为客户端和服务器端信赖的第三方,为其提供初始票据(initial ticket)服务和票据授予票据(ticket-granting ticket)服务,前半部分有时被称为AS,后半部分有时则被称为TGS。

  关于概念的一点补充,博文Kerberos 服务的工作原理中对于TGT和Ticket给出了巧妙的比喻:TGT类似于护照,Ticket则是签证,而访问特定的服务则好比出游某个国家。与护照一样,TGT可标识你的身份并允许你获得多个Ticket(签证),每个Ticket对应一个特定的服务,TGT和Ticket同样具有有效期,过期后就需要重新认证。

2.认证过程

  Kerberos的认证过程可细分为三个阶段:初始验证、获取服务票据和服务验证。第一阶段主要是客户端向KDC中的AS发送用户信息,以请求TGT,然后到第二阶段,客户端拿着之前获得的TGT向KDC中的TGS请求访问某个服务的票据,最后阶段拿到票据(Ticket)后再到该服务的提供端验证身份,然后使用建立的加密通道与服务通信。

2.1 初始验证

  此过程是客户端向AS请求获取TGT:

  • 客户端向AS发送自身用户信息(如用户ID),该动作通常发生在用户初次登陆或使用kinit命令时
  • AS检查本地数据库是否存在该用户,若存在则返回如下两条信息:
    • 消息A:使用用户密钥加密的Client/TGS会话密钥,我们称之为SK1。其中用户密钥是通过对该用户在数据库中对应的密码hash生成的
    • 消息B:使用TGS的密钥加密的TGT(包含客户端ID、客户端网络地址、票据有效期和SK1)
  • 当客户端收到消息A和B时,它会尝试用本地的用户密钥(由用户输入的密码或kerberos.keytab文件中的密码hash生成)对A进行解密,只有当本地用户密钥与AS中对应该用户的密钥匹配时才能解密成功。对A解密成功后,客户端就能拿到SK1,才能与TGS进行后续的会话,这里就相当于AS对客户端的一次验证,只有真正拥有正确用户密钥的客户端才能有机会与AS进行后续会话。而对于消息B,由于它是由TGS的密钥加密的,故无法对其解密,也看不到其中的内容。

2.2 获取服务票据

  此过程则是客户端向TGS请求获取访问对应服务的票据:

  • 当客户端要访问某个服务时,会向TGS发送如下两条消息:

    • 消息C:消息B的内容(即加密后的TGT)和服务ID
    • 消息D:通过SK1加密的验证器(Authenticator,包括用户ID和时间戳)
  • TGS收到消息C和D后,首先检查KDC数据库中是否存在所需服务,若存在则用自己的TGS密钥尝试对C中的消息B进行解密,这里也是客户端对TGS的反向认证,只有真正拥有正确密钥的TGS才能对B解密,解密成功后就能拿到其中的SK1,然后再用SK1解密消息D拿到包含用户ID和时间戳的Authenticator,通过比较分别来自C和D的用户ID,如果二者匹配,则向客户端返回如下两条消息:

    • 消息E:通过SK1加密的Client/SS会话密钥,该会话密钥是KDC新生成的随机密钥,用于将来客户端(Client)与服务端(SS)的通信加密,我们称之为SK2
    • 消息F:使用服务的密钥加密的client-server票据(Ticket,包含用户ID、用户网络地址、票据有效期和SK2),之所以要用服务的密钥加密,是因为这个Ticket是给服务端看的,但又需要经过客户端传给服务端,且不能让客户端看到。那么就会有人问,为什么KDC不直接把消息E发送给服务端呢,这样岂不省事?问题就在于网络时延,若分开发送,消息E和F就不能确保同时到达服务端,考虑一个极端情况,KDC与服务之前的网络临时不通了,那么这段时间服务端就无法收到消息E,导致验证失败,而实际上该客户端是有访问权限的。通过公钥加密这种方式巧妙地回避了该问题
  • 客户端收到消息后,尝试用SK1解密消息E,得到Client/SS会话密钥SK2

2.3 服务验证

  此过程是客户端与服务端相互验证,并通信

  • 客户端向服务端发送如下两条消息:

    • 消息G:即上一步中的消息F——client-server票据

    • 消息H:通过SK2加密的新的验证器(Authenticator,包含用户ID和时间戳)

  • 服务端收到消息后,尝试用自己的密钥解密消息G,这里实际上也是客户端对服务端的一次验证,只有真正拥有正确密钥的服务端才能正确解密,从而有机会拿到Ticket中的SK2,然后再用该SK2解密消息H,同TGS一样,对分别来自Ticket和Authenticator中的用户ID进行验证,如果匹配成功则返回一条确认消息:

    • 消息I:通过SK2加密的新时间戳
  • 客户端尝试用SK2解密消息I,得到新时间戳并验证其正确性,验证通过后,客户端与服务端就达到了相互信任,后续的通信都采用SK2加密,就好比建立了一条加密通道,二者即可享受服务与被服务的乐趣了

3.前提(环境假设)

  • 共享密钥:在协议工作前,客户端与KDC,KDC与服务端都确保有了各自的共享密钥。
  • 防Dos攻击:Kerberos协议本身并没有解决Dos攻击(Denial of service,拒绝服务)防范问题,通常是由系统管理员和用户自己去定期探测并解决这样的攻击。
  • 保障安全个体自身安全:参与到Kerberos协议中的安全个体必须确保其秘钥的安全性,一旦秘钥泄露或被攻击者暴力破解,那么攻击者就能随意地伪装安全个体,做一些不和谐的事情。
  • 不循环利用Principal的唯一标识:访问控制的常用方式是通过访问控制列表(access control lists,ACLs)来对特定的安全个体进行授权。如果列表中有条记录对应的安全个体A早已被删除,而A的唯一标识却被后来新加的某个个体B再次利用,那么B就会继承之前A对应的权限,这是不安全的。避免这种风险的做法就是不复用Principal的唯一标识。
  • 时钟同步:参与到协议中的主机必须有个时钟相互之间进行“松散同步”,松散度是可配置的。为什么需要同步各主机的时间呢?实际上从Kerberos的认证过程可以看到,任何人都可以向KDC请求任何服务的TGT,那攻击者就有可能中途截获正常用户的请求包,然后离线解密,就能合法地拿到TGT。为了防止这种重放攻击,票据(Ticket)会包含时间戳信息,即具有一定的有效期,因此如果主机的时钟与Kerberos服务器的时钟不同步,则认证会失败。在实践中,通常用网络时间协议(Network Time Protocol, NTP)软件来同步时钟。

4.局限性

  • 单点风险:过度依赖于KDC服务,Kerberos协议运转时需要KDC的持续响应,一旦KDC服务挂了,或者KDC数据库被攻破,那么Kerberos协议将无法运转
  • 安全个体自身的安全:Kerberos协议之所以能运行在非安全网络之上,关键假设就是主机自身是安全的,一旦主机上的私钥泄露,攻击者将能轻易的伪装该个体实施攻击

三、Kerberos应用

1.Hadoop安全机制

  Apache Hadoop 最初设计时并没有考虑安全问题,它不对用户或服务进行验证,任何人都可以向集群提交代码并得到执行,使用Hadoop的组织只能把集群隔离到专有网络,确保只有经过授权的用户才能访问,但这也并不能解决Hadoop集群内部的安全问题。为了增强Hadoop的安全机制,从1.0.0版本以后,引入Kerberos认证机制,即用户跟服务通信以及各个服务之间通信均用Kerberos认证,在用户认证后任务执行、访问服务、读写数据等均采用特定服务发起访问token,让需求方凭借token访问相应服务和数据。下面以Yarn中提交MR任务为例:

A、用户先向KDC请求TGT,做初始验证

B、用户通过TGT向KDC请求访问服务的Ticket

C、客户端通过ticket向服务认证自己,完成身份认证

D、完成身份认证后,客户端向服务请求若干token供后续任务执行时认证使用

F、客户端连同获取的token一并提交任务,后续任务执行使用token与服务进行认证

四、其他安全机制

1.OAuth认证

  OAuth(Open Authorization,开放授权)用于第三方授权服务,现常用的第三方账号登陆都是采用该机制。比如我用github账号登陆LeetCode官网,LeetCode并不需要知道我的github账号、密码,它只需要将登陆请求转给授权方(github),由它进行认证授权,然后把授权信息传回LeetCode实现登陆。

2.LDAP

  LDAP(Lightweight Directory Access Protocol,轻量级目录访问协议)是一种用于访问目录服务的业界标准方法,LDAP目录以树状结构来存储数据,针对读取操作做了特定优化,比从专门为OLTP优化的关系数据库中读取数据快一个量级。LDAP中的安全模型主要通过身份认证、安全通道和访问控制来实现,它可以把整个目录、目录的子树、特定条目、条目属性集火符合某过滤条件的条目作为控制对象进行授权,也可以把特定用户、特定组或所有目录用户作为授权主体进行授权,也可以对特定位置(如IP或DNS名称)进行授权。

3.SSL

SSL(Secure Sockets Layer,安全套接层)是目前广泛应用的加密通信协议,其基本思路是采用公钥加密法,即客户端先向服务器端索要公钥,然后用公钥加密信息,服务端收到密文后用自己的私钥解密。它的安全机制包含如下三点:

  • 连接的私密性:利用会话密钥通过对称加密算法(DES)对传输数据进行加密,并利用RSA对会话密钥本身加密
  • 身份验证:基于数字证书利用数字签名方法进行身份验证,SSL服务器和客户端通过PKI(Public Key Infrastructure)提供的机制从CA获取证书
  • 内容可靠:使用基于密钥的MAC(Message Authentication Code,消息验证码)验证消息的完整性,防窜改

© 著作权归作者所有

共有 人打赏支持
sherlockyb
粉丝 8
博文 7
码字总数 33422
作品 0
海淀
程序员
私信 提问
HBase实操 | 如何使用Java连接Kerberos的HBase

一.文档编写目的 出于CDH集群安全考虑,在CDH集群中增加了Kerberos认证机制。因为HBase的存储系统是基于Hadoop的存储,所以通过HBase客户端访问HBase数据库时需要进行身份认证。在Linux下使用...

封神
11/27
0
0
freeipa kinit 报错处理

freeipa 在添加用户时输入 kinit 报错,kinit: Client '' not found in Kerberos database while getting initial credentials,找不到kerberos 数据库。输入kinit admin 即可。...

酒瓶不倒
2014/12/12
0
0
CDH5.X安装配置kerberos认证过程

CDH-5.2.0-1.cdh5.2.0安装成功,已经运行了几个月了。现在把确实的认证安装配置上。下面是详细的安装配置过程,已经过程中遇到的问题解决办法。 1. 背景 在Hadoop1.0.0或者CDH3 版本之前,h...

dannyhe
2015/09/29
700
0
使用MacPort安装了Kerberos后ssh无法使用Kerberos验证

最近想把本配置成公司的开发环境,在登录到服务器的时候遇到了问题,我把Kerberos配置好,kinit以后登录服务器,还是让我输入密码。后来发现是MacPort安装了Kerberos,把MacPort安装的Kerbe...

SwordHua
2013/02/08
0
0
HAS-插件式Kerberos认证框架

HAS解决方案要点 Hadoop服务以及服务之间继续使用原先的Kerberos的认证机制; 在集群部署的时候可以把节点使用的Keytab放到可靠的节点上, 集群运行时,集群内的节点只有通过认证后才能正常使...

寒沙牧
2017/12/25
0
0

没有更多内容

加载失败,请刷新页面

加载更多

EOS官方钱包keosd

EOS官方钱包的名称是keosd,它负责管理你的私钥,并且帮你进行交易的签名。 不过不幸的是,keosd钱包对普通用户并不友好,它是一个命令行程序,目前还没有像以太坊的mist那样的图形化界面,而...

汇智网教程
今天
25
0
ArrayList的实现原理以及实现线程安全

一、ArrayList概述 ArrayList是基于数组实现的,是一个动态的数字,可以自动扩容。 ArrayList不是线程安全的,效率比较高,只能用于单线程的环境中,在多线程环境中可以使用Collections.syn...

一看就喷亏的小猿
今天
30
0
Netty 备录 (一)

入职新公司不久,修修补补1个月的bug,来了点实战性的技术---基于netty即时通信 还好之前对socket有所使用及了解,入手netty应该不是很难吧,好吧,的确有点难,刚看这玩意的时候,可能都不知道哪里...

_大侠__
昨天
34
0
Django简单介绍和用户访问流程

Python下有许多款不同的 Web 框架。Django是重量级选手中最有代表性的一位。许多成功的网站和APP都基于Django。 Django是一个开放源代码的Web应用框架,由Python写成。 Django遵守BSD版权,初...

枫叶云
昨天
47
0
Spring Cloud Stream消费失败后的处理策略(四):重新入队(RabbitMQ)

应用场景 之前我们已经通过《Spring Cloud Stream消费失败后的处理策略(一):自动重试》一文介绍了Spring Cloud Stream默认的消息重试功能。本文将介绍RabbitMQ的binder提供的另外一种重试...

程序猿DD
昨天
23
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部