javakerberos认证,kerberos认证协议
Kerberos认证原理与环境部署
官网：
官方文档：
Kerberos中有以下一些概念需要了解：
用户principal的形式：
其中Instance是可选 的，通常用于更好地限定用户的类型。比如，一个管理员用户通常会有admin instance，即 Name/admin@REALM 。
下面是指代用户的 一些principal的例子：
用户principal的形式：
下面是指代服务principal的例子：
Ticket分两种：
Kerberos认证时序图：
官方文档：
在 hadoop-node1 节点上执行如下命令安装Kerberos Server
其中前一个 号是通配符，表示像名为“abc/admin”或“xxx/admin”的人都可以使用此工具（远程或本地）管理kerberos数据库，后一个 跟权限有关，*表示所有权限。HADOOP.COM是上面配置的realm。
Kerberos kadmind 使用该文件来管理对 Kerberos 数据库的访问权限。对于影响 principa 的操作，ACL 文件还控制哪些 principa 可以对哪些其他 principa 进行操作。文件格式如下：
相关参数说明：
【示例】
kadm5.acl 文件中的以下项授予 HADOOP.COM 领域中包含 admin 实例的任何主体对 Kerberos 数据库的所有权限：
kadm5.acl 文件中的以下项 授予 test@EXAMPLE.COM 主体添加、列出和查询包含 root 实例的任何主体的权限。
kadm5.acl 文件中的以下项 不授予 test@EXAMPLE.COM 主体添加、列出和查询包含 root 实例的任何主体的权限。
详细说明可参考官网文档：
kerberos数据库创建完之后，默认会创建以下5个文件（kdc.conf、kadm5.acl除外的其他几个），Kerberos 数据库的目录为： /var/kerberos/krb5kdc ，如果需要重建数据库，可删除这五个文件重新执行上面的命令创建。
启动：
停止：
Kerberos 服务机器上可以使用 kadmin.local 来执行各种管理的操作。进入 kadmin.local，不需要输入密码：
常用操作：
【示例】
在hadoop-node2和hadoop-node3节点上安装client
配置 krb5.conf
测试验证连接server
指定用户
管理KDC数据库有两种方式：
创建用户，注意自己设置的密码
使用xst命令或者ktadd命令：
其中 /root/root.keytab为自己指定的路径与文件名，以.keytab结尾；root/admin为之前创建的凭证用户
查看密钥文件
基于密码认证
基于密钥认证（keytab）
常见的基础操作就到这里了，更多操作命令，可以查看官方文档和查看帮助。后续会分享kerberos认证实战文章，请小伙伴耐心等待~
Kerberos认证原理
在keberos Authentication中，Kerberos有三个主体：Client、Server和KDC。
为了便于理解，这里引入两个关键的概念：
以上就是Kinit 做的事情，以后访问各个Service就用这个加密的TGT就可以了。
真正运行访问Service的程序时，进行一下步骤：
Client向Server发送的数据包被某个恶意网络监听者截获，该监听者随后将数据包座位自己的Credential冒充该Client对Server进行访问，在这种情况下，依然可以很顺利地获得Server的成功认证。为了解决这个问题，Client在Authenticator中会加入一个当前时间的Timestamp。在Server对Authenticator中的Client Info和Session Ticket中的Client Info进行比较之前，会先提取Authenticator中的Timestamp，并同当前的时间进行比较，如果他们之间的偏差超出一个可以接受的时间范围（一般是5mins），Server会直接拒绝该Client的请求。
Kerberos一个重要的优势在于它能够提供双向认证：不但Server可以对Client 进行认证，Client也能对Server进行认证。具体过程是这样的，如果Client需要对他访问的Server进行认证，会在它向Server发送的Credential中设置一个是否需要认证的Flag。Server在对Client认证成功之后，会把Authenticator中的Timestamp提出出来，通过Session Key进行加密，当Client接收到并使用Session Key进行解密之后，如果确认Timestamp和原来的完全一致，那么他可以认定Server正式他试图访问的Server。
那么为什么Server不直接把通过Session Key进行加密的Authenticator原样发送给Client，而要把Timestamp提取出来加密发送给Client呢？原因在于防止恶意的监听者通过获取的Client发送的Authenticator冒充Server获得Client的认证。
delegation token其实就是hadoop里一种轻量级认证方法，作为kerberos认证的一种补充。理论上只使用kerberos来认证是足够了，为什么hadoop还要自己开发一套使用delegation token的认证方式呢？这是因为如果在一个很大的分布式系统当中，如果每个节点访问某个服务的时候都使用kerberos来作为认证方式，那么势必对KDC造成很大的压力，KDC就会成为一个系统的瓶颈。
kerberos认证需三方参与，client， kdc， server三方协作完成认证。
Delegation token的认证只需要两方参与，client和server。而且可以传递给其它服务使用，这也是它叫delegation token的原因。比如在client端获取到hdfs delegation token后，可以分发到各个executor，各个task就可以不通过kerberos直接使用token访问hdfs
delegation token有过期时间，一般 token每24小时刷新一次，否则就失效，且token寿命为7天，七天后该token就不能再使用。
对于spark streaming, storm等这种长时运行应用来说，不得不面临一个问题：token存在最大生命周期。当token达到其最大生命周期的时候，所有的工作节点（比如spark streaming的executor）中使用的token都会失效，此时在使用该token去访问hdfs就会被namenode拒绝，导致应用异常退出。
一种解决思路是将keytab文件分发给Am及每个container，让am和container去访问kdc来认证，但这种方式会给KDC造成很大的访问压力，导致KDC会误认为自己遭受了DDos攻击，从而影响程序性能。
另一种解决思路是先由client把keytab文件放到hdfs上。然后在Am中使用keytab登录，并申请delegation token。Am在启动worker的时候把该token分发给相应的容器。当token快要过期的时候，Am重新登录一次，并重新获取delegation token，并告知所有的worker使用更新后的token访问服务。
spark使用的就是第二种解决思路，spark 为了解决DT失效问题，加了两个参数"--keytab"和"--principal"，分别指定用于kerberos登录的keytab文件和principal，通过在AM中login然后定期更新token实现了任务七天不挂
如何利用JAAS实现一个认证授权的例子
Kerberos已经配置完成。
在java测试程序中设置Kerberos的相关属性
Properties props = new Properties();
props.load(new FileInputStream("client.properties"));
System.setProperty("sun.security.krb5.debug", "true");
System.setProperty("java.security.krb5.realm",
props.getProperty("realm"));
System.setProperty("java.security.krb5.kdc",
props.getProperty("kdc"));
client.properties具体内容如下所示：
设置登录Kerberos使用的配置文件和用到的用户名和密码
System.setProperty("java.security.auth.login.config", "./jaas.conf");
System.setProperty("javax.security.auth.useSubjectCredsOnly",
"false");
String username = props.getProperty("client.principal.name");
String password = props.getProperty("client.password");
jaas.conf配置文件如下所示：主要看此文件Client备份配置内容，可以看到jaas登录使用的是Krb5LoginModule模式
使用LoginContext类完成认证。此时的关键参数为用户名和密码。
使用LoginContext类进行认证时，调用了回调类LoginCallbackHandler。此类主要是对用户名和密码的处理。
认证通过后获取一个subject。获取subject后就可通过此授权进行相关操作了。
Kafka Kerberos 安全认证
本主要介绍在 Kafka 中如何配置 Kerberos 认证，文中所使用到的软件版本： Java 1.8.0_261 、 Kafka_2.12-2.6.0 、 Kerberos 1.15.1 。
要使用 Kerberos 服务，需先安装 Kerberos，安装方法可参考： Kerberos 安装及使用 。
节点信息如下：
在安装 Kerberos 的机器上进入 kadmin（Kerberos 服务端上使用 kadmin.local ，安装了 Kerberos Client 的机器上可以使用 kadmin ），然后执行如下命令分别创建服务端和客户端的 keytab：
拷贝 krb5.conf 及 keytab 文件到所有安装 Kafka 的机器，把文件都放到 Kafka 的 config/kerveros 目录下(kerberos 目录需新建)。
复制 config/server.properties（复制动作能帮助我们在 认证/非认证 模式自由切换）重命名为 config/server-sasl.properties ，增加如下配置：
新建 kafka-server-jaas.conf 文件，该文件也放到 Kafka 的 config/kerveros 目录下：
复制 bin/kafka-server-start.sh 脚本重命名为 bin/kafka-server-start-sasl.sh ，倒数第二行增加如下配置：
该配置主要为了使用 bin/kafka-topics.sh、bin/kafka-console-consumer.sh、kafka-console-producer.sh 等命令。
新建 client.properties 文件，该文件也放到 Kafka 的 config/kerveros 目录下：
新建 kafka-client-jaas.conf 文件，该文件也放到 Kafka 的 config/kerveros 目录下：
复制 bin/kafka-topics.sh、kafka-console-producer.sh、bin/kafka-console-consumer.sh 脚本，分别重命名为 bin/kafka-topics-sasl.sh 、 kafka-console-producer-sasl.sh 、 bin/kafka-console-consumer-sasl.sh ，倒数第二行增加如下配置：
运行 bin/kafka-server-start-sasl.s 启动 Kafka 集群：
运行 bin/kafka-topics-sasl.sh 查看 topic 列表信息：
运行 kafka-console-producer-sasl.sh 生产消息：
运行 bin/kafka-console-consumer-sasl.sh 消费消息：
java 可以使用 JAAS 来进行 Kerberos 认证，需要 JAAS 配置文件、keytab 文件及 Kerberos 配置文件。
在 C:\Windows\System32\drivers\etc\hosts 文件中添加：
实际上，样例程序中的种种设置就是为了还原我们在上一步中改动 bin/kafka-console-consumer-sasl.sh + config/kerberos/client.properties 的过程，二者是对应的：
报错原因是 keytab 文件不正确，可能是 principle 不匹配或其它配置文件错误。本文中所犯错误是，Windows 的路径要写双斜线，否则配置文件无法正确读取。
报错的可能原因之一是未配置 hosts 文件。认证策略中肯能会使用缓存，配置了 hosts 文件后要重启 IDE。
Kerberos模型认证原理是什么?
Kerberos的认证原理：
Kerberos采用可信赖第三方服务器进行密钥分发和身份确认，包括：
① 对用户认证
② 对应用服务的提供者进行认证。
此外，还可根据用户要求提供客户/服务器间的数据加密与完整性服务。
RFC1510协议文件对V5作了如下说明：
Kerberos提供了在开放型网络中进行身份认证的方法，认证实体可以是用户或用户服务。这种认证不依赖宿主机的操作系统或主机的IP地址，不需要保证网络上所有主机的物理安全性，并且假定数据包在传输中可被随机窃取篡改。
2?Kerberos的主要概念及一个工作
模型
DES：对信息加密的算法。V4只支持这一DES(数据加密标准)算法，V5采用独立的加密模块，可用其它加密算法替换。
主体Principal:用户或服务，具体格式为〈登录名Primary name，实体名lnstance,域名realm〉
许可证Ticket:向Kerberos server认证的凭证。
格式〈Primary name,会话密钥Sessionkey，时间戳Timestamp〉会话密钥Session key:两个主体通信的临时密钥。
KDC(密钥发送中心)：包括认证服务器AS(Authenticatin server)
用于用户的初始认证服务。
和TGS(Ticket Granting server)许可证认证服务器。
AS和TGS同驻于一台主机上。
认证符Authenticator.用户创建的令牌。发送给服务器用于证明用户身份
格式〈primary name ,timestamp
一个Kerberos服务器也称为密钥分发中心KDC，维护着一个数据库.里面保存着所辖域内的用户及服务器的DES密钥。DES密钥基于用户口令而生。用户首次注册时，系统根据用户口令生成密钥。应用服务器向KDC注册也生成密钥，这个密钥既存放在KDC上，也存于该服务器的主机上。
现在假定一用户需要某应用服务器提供服务，工作模型如下：
从此例可以看出，基于Needham-schroeder密钥协议的Kerberos系统保障了网络传输和通信的安全。
但用户的负担十分繁重：用户的目的是得到应用服务器S的服务，却不得不积极地申请许可证!
在KerberosV4版里，为防止“重放”攻击，nonce由时间戳实现，这就带来了时间同步问题。即使利用网络时间协议(Network Time Protocol)或国际标准时间(Coordinated universal time)能在一定程度上解决时间同步问题，用户需要承担的责任也令人忍受。
Kerberos V5 版允许nonce可以是一个数字序列，但要求它唯一。由于服务器无法保证不同用户的nonce不冲突，偶然的冲突可能将合法用户的服务器申请当作重放攻击而拒之门外。
简言之，从没有网络安全知识的用户角度来看，Kerberos以加大用户参与安全保证的力度（而他们并不具备这方面的知识更没有耐心）来保障通信的安全，这种做法并不可行。