官网：https://web.mit.edu/kerberos/

一、What is Kerberos?

使用基于密码学的key文件进行CS间强认证的网络认证协议

密码学的key文件
这样客户机就可以通过不安全的网络连接向服务器(反之亦然)证明自己的身份。在客户端和服务器使用Kerberos来证明其身份之后，它们还可以对所有通信进行加密，以确保在处理业务时的隐私和数据完整性。
cs间
强认证
默认情况下，服务都是弱认证，client说自己是谁server就认为它是谁
网络协议
类似于http协议，提供了通信标准，包括：
数据发送和接收的格式
使用对称密钥体系

二、What problem did it solved？

解决了网络间节点的认证问题。
1. 默认情况下，大数据的组件都是默认客户端是经过认证的合法用户，客户端用哪个用户名连接，服务端就给这个连接赋对应权限。这显然是不安全的。
  1. 比如hdfs，可以在windows或者linux中设置export HADOOP_USER_NAME的环境变量来指定用户，说自己是谁就是谁。这就是软认证，kerberos就是用来进行强认证的，client不仅要说自己是谁principal，还要通过密码来证明
2. 一些sites试图用防火墙来解决他们的网络安全问题。但防火墙的局限是假设“坏人”在外部，这通常是一个非常糟糕的假设。大多数真正具有破坏性的计算机犯罪事件都是由内部人员实施的。防火墙还有一个明显的缺点，那就是它限制了用户使用互联网的方式。

三、理解

1.架构、角色设计

Kerberos提供了一种单点登录(SSO)的方法。假设这样一个场景，在一个网络中有不同的服务器，比如，打印服务器、邮件服务器和文件服务器。这些服务器都有认证的需求。显然，不可能让每个服务器自己实现一套认证系统，而是提供一个中心认证服务器（AS-Authentication Server）供这些服务器使用。这样任何客户端就只需维护一个密码就能登录所有服务器。
因此，在Kerberos系统中至少有三个角色：认证服务器（AS），客户端（Client）和普通服务器（Server）。客户端和服务器将在AS的帮助下完成相互认证。
在Kerberos系统中，客户端和服务器都有一个唯一的名字，叫做Principal。同时，客户端和服务器都有自己的密码，并且它们的密码只有自己和认证服务器AS知道。

假如你要去社区中心去办理居住证，但是社区中心并不能确定你的身份，因此需要你去派出所开据证明，证明你就是你。那么，通常的流程是这样的：

派出所一开始要将你的资料注册到系统中
你带材料去派出所，JC根据他们的内部系统，核实你提供的材料并开据你确实是你的证明。
再拿着这个证明去社区中心，社区中心现在就可以确定你的身份，便开始给你办理业务。
kerberos于此不同的地方在于kerberos提供了1个基本的授权功能，相当于派出所还要给你开1个可以办居住证的证明

2.角色

2.1 KDC：3大组件。也就是kerberos的server

AS：认证服务器
要想使用kerberos，无论是用户还是服务，第一步都是现在kerberos中注册
Database：存的就是principal和密钥。虽然叫数据库，但实际上是个文件夹
TGS：Ticket Granting Server票据授权服务器，kerberos提供基本的授权功能，权限就2种：是否能访问该服务，其实本质就是认证，比如hive服务，hive用户能访问，别的不能。
TGS就是替服务判断这个用户能否访问，比如hive服务，spark用户不能访问，spark在AS证明自己是自己后，如果访问hive，hive会提示无法登录，但这就脱离kerberos的控制了，所以kerberos要把这一功能封装。

2.2 client：所有需要认证的模块，不仅仅是节点，也可能是进程

2.3 Realm：就是由KDC和kerberos客户端组成的网络。是principal命名空间的一部分。

2.4 principal：用户或服务的唯一标识，用户和服务都需要认证。是唯一标识，3层结构：realm/实例/用户名

syntax格式：主名称/实例名@领域名

实例：就是用户组或主机名，kerberos中实例仅仅象征意义，占位作用，实例在kerberos中唯一的作用就是赋管理kerberos的权限。在sentry中才用得到。比如，无论是hive/hive，还是hive/xxx，只要是hive用户，都可以访问hive服务，kerberos不在乎实例是什么。

服务的主名称是用户名或服务名，比如hdfs、spark，服务的实例就是主机名

2.5 TGT：ticket for getting tickets，ticket有2种，TGT和server ticket

2.6 keytab：包含一个或多个principal及其密码的文件，keytab + principal可以完成认证

3.认证原理

须知：

简单说，kerberos解决了用户和KDC、用户和服务的证明自己是自己的问题。
- kerberos会拦截所有发向集群服务的请求，拦截后会自动去本地缓存中找ticket，找到就放行
- 没有kerberos时，client说自己是谁就是谁，默认就用linux系统的登录用户或者env中的HADOOP_USER_NAME配置的。
- 用了kerberos，需要向AS提供自己的principal + 密码或keytab，AS认证成功后，发给client1个TGT，证明用户的确是这个用户。也就是认证成功，但认证成功不代表能访问服务，必须要是对应的用户才行，kerberos的TGS替服务来判断这个。从TGS获取服务的server ticket后，就可以访问对应的服务了。

1.不用kerberos时，登录哪个服务，哪个服务认证就行了。现在引入了1个第三方，第三方认证通过了，怎么让服务知道？

TGS
TGT + server ticket

在这里插入图片描述

四、

五、在apache中安装配置kerberos

1.安装

1.1 server节点安装，server节点就是KDC节点

krb5-workstation是客户端，krb5-server是服务端 + kadmin数据库

[root@hadoop102 ~]# yum install -y krb5-server krb5-workstation krb5-libs
#查看结果，此处有坑，我第一次安就没有把krb5-server安上，所以要查一下以防万一
[root@hadoop102 ~]# rpm -qa | grep krb5
krb5-workstation-1.10.3-65.el6.x86_64
krb5-libs-1.10.3-65.el6.x86_64
krb5-server-1.10.3-65.el6.x86_64

1.2 client节点和server节点都安装

[root@hadoop102 ~]# yum install -y krb5-workstation krb5-libs
[root@hadoop103 ~]# yum install -y krb5-workstation krb5-libs
[root@hadoop104 ~]# yum install -y krb5-workstation krb5-libs
#查看结果
[root@hadoop103 ~]# rpm -qa | grep krb5
krb5-workstation-1.10.3-65.el6.x86_64
krb5-libs-1.10.3-65.el6.x86_64

2.配置kerberos

只需要配置2个文件：kdc.conf和krb5.conf

2.1 server的kdc.conf

须知：

realm一般是大写，用域名的方式描述，比如HADOOP.COM，用来装hadoop相关的用户
HADOOP.COM：realm名称，Kerberos支持多个realm，一般全用大写。
acl_file:admin的用户权。
admin_keytab:KDC进行校验的keytab。
supported_enctypes:支持的校验方式，注意把aes256-cts去掉，JAVA使用aes256-cts验证方式需要安装额外的jar包，所有这里不用
max_life：表示1次认证的有效期，kerberos有效期设计的很特别，一次认证后，会从AS下载TGT放到缓存，有效期过了之后就删除缓存，然后自动根据max_renewable_life 重新认证1次，这次再过期，就不自动再认证了。

[root@hadoop102 ~]# vi /var/kerberos/krb5kdc/kdc.conf
[kdcdefaults]
 kdc_ports = 88
 kdc_tcp_ports = 88

[realms]
 HADOOP.COM = {
  # master_key_type = aes256-cts
  # access control list，权限列表，保存当前realm下所有用户、实例的权限。
  acl_file = /var/kerberos/krb5kdc/kadm5.acl 
  dict_file = /usr/share/dict/words
  admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
  # 认证有效期和自动重新认证有效期
  max_life = 1d
  max_renewable_life = 7d
  # 支持的校验方式，注意把aes256-cts去掉，JAVA使用aes256-cts验证方式需要安装额外的jar包，所以这里不用
  supported_enctypes = aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal camellia256-cts:normal camellia128-cts:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal
 }

2.2 client的krb5.conf

须知：

default_realm：默认的realm，设置 Kerberos 应用程序的默认领域，必须跟要配置的realm的名称一致。
ticket_lifetime：表明凭证生效的时限，一般为24小时。
renew_lifetime ：表明凭证最长可以被延期的时限，一般为一个礼拜。当凭证过期之后，对安全认证的服务的后续访问则会失败。
udp_preference_limit= 1：禁止使用 udp，可以防止一个 Hadoop 中的错误。
realms：配置使用的 realm，如果有多个领域，只需向 [realms] 节添加其他的语句。
domain_realm：集群域名与realm的映射关系，单个realm的情况下，可忽略。
example.com = EXAMPLE.COM是在说：所有在example.com域下的主机都会被映射到EXAMPLE.COM这个realm下，而example.com = EXAMPLE.COM是说example.com它自己也会映射到EXAMPLE.COM这个realm。
一般一个集群设置1个realm，当要设置2个集群通信时，需要在一个krb5.conf中设置多个realmhttps://www.jianshu.com/p/2281e3fe6485

[root@hadoop102 ~]# vi /etc/krb5.conf
includedir /etc/krb5.conf.d/
# 日志文件路径
[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log
# 默认配置
[libdefaults]
 dns_lookup_realm = false
 # 这个的作用跟kdc.conf中的max_life和max_renewable_life = 7d相同，但作用域不同。server上的管理当前realm，这里配的是default_realm
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true
 rdns = false
 pkinit_anchors = /etc/pki/tls/certs/ca-bundle.crt
 # 这个默认注释，一般解开，这样认证时就不用写realm名字
 default_realm = HADOOP.COM
 # 这个要注释掉
 #default_ccache_name = KEYRING:persistent:%{uid}
 # 禁用udp，防止报错
 udp_preference_limit = 1
# 客户端访问server，需要有realm的信息
[realms]
 HADOOP.COM = {
  kdc = node105
  # KDC中数据库的地址
  admin_server = node105 
 }
# kerberos能管理多个realm，服务和realm需要建立映射，这里通过域名和realm的映射来实现。如果只有1个realm，这里就不用配置
[domain_realm]
# .example.com = EXAMPLE.COM
# example.com = EXAMPLE.COM

配完要分发：`[root@node105 ~]# rrsync /etc/krb5.conf`

2.3 创建数据库

这里的数据库实际上就是个文件夹，在/var/kerberos/krb5kdc下

在server节点执行

[root@node105 ~]# kdb5_util create -s
Loading random data
Initializing database '/var/kerberos/krb5kdc/principal' for realm 'HADOOP.COM',
master key name 'K/[email protected]'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key: （输入密码）
Re-enter KDC database master key to verify:（确认密码）

创建完成后/var/kerberos/krb5kdc目录下会生成对应的文件

[root@hadoop102 ~]# ls /var/kerberos/krb5kdc/
kadm5.acl  kdc.conf  principal  principal.kadm5  principal.kadm5.lock  principal.ok
# 如想重建，删除这4个即可principal  principal.kadm5  principal.kadm5.lock  principal.ok

2.4 启动kerberos的Server

#启动krb5kdc
[root@hadoop102 ~]# systemctl start krb5kdc
正在启动 Kerberos 5 KDC：                                  [确定]

#启动kadmin
[root@hadoop102 ~]# systemctl start kadmin
正在启动 Kerberos 5 Admin Server：                         [确定]

#设置开机自启
[root@hadoop102 ~]# systemctl enable krb5kdc
#查看是否设置为开机自启
[root@hadoop102 ~]# systemctl is-enabled krb5kdc

[root@hadoop102 ~]# systemctl enable kadmin
#查看是否设置为开机自启
[root@hadoop102 ~]# systemctl is-enabled kadmin

注意：

启动失败时可以通过/var/log/krb5kdc.log和/var/log/kadmind.log来查看。
必须先创建数据库才能启动

六、在apache中操作kerberos

2种操作，注册、认证

1.注册，就是在数据库中创建principal，通过操作kerberos数据库完成

1.1 登录kerberos数据库

{1} 本地登录（无需认证），在KDC本地登录

[root@hadoop102 ~]# kadmin.local
Authenticating as principal root/[email protected] with password.
kadmin.local:
本地登录后默认用root/admin登录，最高权限，可以CRUD主体
登录后会有命令提示
在这里插入图片描述
klist ：查看认证成功的principal，认证成功就会有ticket的缓存

{2} 远程登录（server需启动kadmin服务），kadmin.local要改为kadmin

[root@node105 ~]# kadmin
Authenticating as principal admin/[email protected] with password.
Password for admin/[email protected]:
kadmin:
退出输入：exit或quit

[root@node106 ~]# kadmin --h
kadmin: invalid option -- '-'
Usage: kadmin [-r realm] [-p principal] [-q query] [clnt|local args]
              [command args...]
	clnt args: [-s admin_server[:port]] [[-c ccache]|[-k [-t keytab]]]|[-n]
	local args: [-x db_args]* [-d dbname] [-e "enc:salt ..."] [-m]where,
	[-x db_args]* - any number of database specific arguments.
			Look at each database documentation for supported arguments

如想指定principal，用kadmin -p cloudera-scm/admin

1.2 创建principal，就是注册

[root@node105 ~]# kadmin.local -q “addprinc admin/admin[@HADOOP.COM]”
realm配置了默认的，可以省略
实例名也可以省
Authenticating as principal root/[email protected] with password.
WARNING: no policy specified for admin/[email protected]; defaulting to no policy
Enter password for principal “admin/[email protected]”: （输入密码）
Re-enter password for principal “admin/[email protected]”: （输入密码）
Principal “admin/[email protected]” created.

1.2 修改principal密码

[root@node105 ~]# kadmin.local -q “cpw admin/admin”
Authenticating as principal root/[email protected] with password.
Enter password for principal “admin/[email protected]”: （输入密码）
Re-enter password for principal “admin/[email protected]”: （输入密码）
Password for “admin/[email protected]” changed.

1.3 查看所有principal

[root@node105 ~]# kadmin.local -q “list_principals”
Authenticating as principal root/[email protected] with password.
K/[email protected]
admin/[email protected]
kadmin/[email protected]
kadmin/[email protected]
kadmin/[email protected]
kiprop/[email protected]
krbtgt/[email protected]

2.认证

Kerberos提供了两种认证方式，一种是通过输入密码认证，另一种是通过keytab密钥文件认证，但两种方式不可同时使用。有密钥文件的情况下，用密码认证，即使密码正确也会提示密码错误
比如在sqoop脚本中登录hive时，用密码的方式不方便（使用密码方式，密码不能写在命令里，命令中写principal，然后在命令行中输入密码），可以用keytab文件的方式，只需要指定文件的位置。
认证成功后，认证文件会缓存在本机的/tmp目录下。有这个文件就可以一直处于认证状态，销毁就是把这个文件删掉。

原来是我说我是谁就是谁，现在需要KDC认证我是谁，服务就认为我是谁

2.1 密码认证

{1} kinit命令

[root@node105 ~]# kinit admin/admin
Password for admin/[email protected]:
[root@node105 ~]# klist

2.2 keytab密钥文件认证

首要要有keytab，然后再用。
keytab文件包含指定principal认证的所有信息，只要提供这个文件和指定principal，就可以认证成功

{1} 生成主体admin/admin的keytab文件到指定目录/root/admin.keytab

xst -k 密钥文件保存目录 哪个principal的
一般保存到对应linux用户的家目录中
[root@hadoop102 ~]# kadmin.local -q "xst -k /root/admin.keytab admin/[email protected]"

在这里插入图片描述

{2} 使用kinit -kt + keytab进行认证

[root@node105 ~]# kinit -kt /root/admin.keytab admin/admin

{3} 查看、销毁认证凭证

[root@hadoop102 ~]# klist 
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: admin/admin@HADOOP.COM

Valid starting     Expires            Service principal
08/27/19 15:41:28  08/28/19 15:41:28  krbtgt/HADOOP.COM@HADOOP.COM
        renew until 08/27/19 15:41:28

[root@hadoop102 ~]# kdestroy
[root@hadoop102 ~]# klist   
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0)

七、在CDH中配置kerberos

1.手动完成kerberos的安装配置，也就是 `五` 中的操作

安装server(kdc)和client(kadmin)
/var/kerberos/krb5kdc/kdc.conf中配置server：realm
/etc/krb5.conf中配置client：访问server时的默认realm，realm的地址

2.为admin实例赋予所有权限

这里的权限指的是kadmin数据库中CRUD principal的权限，

[root@hadoop102 ~]# vi /var/kerberos/krb5kdc/kadm5.acl
#一共2列，主题 \t 权限
*/admin@HADOOP.COM      *
说明：
*/admin：admin实例的全部主体
@HADOOP.COM：realm
*：全部权限
就是授予admin实例的全部主体对应HADOOP.COM领域的全部权限。也就是创建Kerberos主体的时候如果实例为admin,就具有HADOOP.COM领域的全部权限，比如创建如下的主体user1/admin就拥有全部的HADOOP.COM领域的权限。

`注意：设完权限要重启krb5kdc和kadmin`

3.为CM创建管理员主体/实例，因为cm要通过所有组件的认证，所有要创建对应的principal

[root@node105 ~]# kadmin.local -q "addprinc cloudera-scm/admin"
Authenticating as principal root/admin@HADOOP.COM with password.
WARNING: no policy specified for cloudera-scm/admin @HADOOP.COM; defaulting to no policy
Enter password for principal " cloudera-scm/admin @HADOOP.COM": （输入密码）
Re-enter password for principal " cloudera-scm/admin @HADOOP.COM": （确认密码）
Principal " cloudera-scm/admin @HADOOP.COM" created.

4.CM-UI中启动kerberos

4.1 启动所有服务，下拉箭头-启动kerberos

aes128-cts、des3-hmac-sha1、arcfour-hmac
这里不选
cloudera-scm/admin dcdcdc 设置cloudera-scm的principal和密码，是通过密码认证的
然后设置重启

注意：此处我因为之前设置/var/kerberos/krb5kdc/kadm5.acl没重启，导致创建principal时失败，此时重启后可以在管理-安全-凭证中重新生成

查看所有主体，也可以在UI中查看

[root@node105 kerberos]# kadmin.local -q "list_principals"
Authenticating as principal cloudera-scm/admin@HADOOP.COM with password.
HTTP/node105@HADOOP.COM
HTTP/node106@HADOOP.COM
HTTP/node107@HADOOP.COM
K/M@HADOOP.COM
cloudera-scm/admin@HADOOP.COM
hdfs/node105@HADOOP.COM
hdfs/node106@HADOOP.COM
hdfs/node107@HADOOP.COM
hive/node105@HADOOP.COM
hue/node105@HADOOP.COM
impala/node105@HADOOP.COM
impala/node106@HADOOP.COM
impala/node107@HADOOP.COM
kadmin/admin@HADOOP.COM
kadmin/changepw@HADOOP.COM
kadmin/node105@HADOOP.COM
kiprop/node105@HADOOP.COM
krbtgt/HADOOP.COM@HADOOP.COM
mapred/node106@HADOOP.COM
oozie/node105@HADOOP.COM
spark/node106@HADOOP.COM
yarn/node105@HADOOP.COM
yarn/node106@HADOOP.COM
yarn/node107@HADOOP.COM
zookeeper/node105@HADOOP.COM
zookeeper/node106@HADOOP.COM
zookeeper/node107@HADOOP.COM

5.`至此，CDH整合kerberos完毕。此时，系统与系统（flume-kafka）之间的通讯，以及用户与系统（user-hdfs）之间的通讯都需要先进行安全认证，认证通过之后方可进行通讯。数仓中使用的脚本等，均需要加入一步安全认证的操作，才能正常工作。需要在脚本中执行kinit命令来给当前的连接认证`

5.1 客户端访问服务

须知：

CDH自动创建的principal都是服务的principal，实例都是节点名，要想创建用户的，要自己创建
以往访问hdfs，可以sudo hdfs hadoop fd -ls /，现在这么访问会报错，必须进行hdfs用户的认证，而认证前要手动创建hdfs的principal，这里实例名一般和服务名相同，比如hdfs的principal：hdfs/[email protected]，也不需要给hdfs实例授权，这里的实例应该是由之后的sentry来使用，这里仅仅是占个位。
认证就是证明用户是用户，用户提交的信息和KDC上已有的信息一致即可。
认证是以节点为单位，这个节点上有了服务A的缓冲，这个节点上所有连接都可以访问A服务

kafka

浏览器认证HDFS WebUI

5.2 服务之间

flume - kafka - hdfs

1）日志采集Flume配置
日志采集Flume，数据被发送到了Kafka，该Flume相当于一个Kafka生产者。所以需要进行上述Kafka客户端的安全认证。但是此处不需要我们进行手动配置，在开启Kerberos后，CM会自动进行配置。
2）消费Kafka Flume配置
消费Kafka Flume，将数据从Kafka传输到HDFS，该Flume相当于一个Kafka消费者。所以也需要进行上述Kafka客户端的安全认证（无需手动认证）。除此之外，还需要进行HDFS客户端的安全认证，这需要我们手动配置。

flume中的sink提供了配置kerberos的属性

##sink2
a1.sinks.k2.type = hdfs
#a1.sinks.k2.hdfs.proxyUser=hive
# kerberos
a1.sinks.k2.hdfs.kerberosPrincipal=hive/hive@HADOOP.COM
a1.sinks.k2.hdfs.kerberosKeytab=/var/lib/hive/hive.keytab

a1.sinks.k2.hdfs.path = /origin_data/gmall/log/topic_event/%Y-%m-%d
a1.sinks.k2.hdfs.filePrefix = logevent-
a1.sinks.k2.hdfs.round = true
a1.sinks.k2.hdfs.roundValue = 10
a1.sinks.k2.hdfs.roundUnit = second

5.3 脚本中：

kinit -kt /opt/hive.keytab hive/hive
beeline -u "jdbc:hive2://hadoop102:10000/;principal=hive/[email protected]" -n hive -e "$sql"
这里的principal是要访问的主体，认证hive/hive，访问hive/node105

#!/bin/bash

kinit -kt /opt/hive/hive.keytab hive/hive
# 定义变量方便修改
APP=gmall

# 如果是输入的日期按照取输入日期；如果没输入日期取当前时间的前一天
if [ -n "$1" ] ;then
   do_date=$1
else 
   do_date=`date -d "-1 day" +%F`
fi 

echo "===日志日期为 $do_date==="
sql="
load data inpath '/origin_data/gmall/log/topic_start/$do_date' into table "$APP".ods_start_log partition(dt='$do_date');
"

beeline -u "jdbc:hive2://node105:10000/;principal=hive/[email protected]" -n hive -e "$sql"

5.4

八、测试

须知：

CDH的hive服务的principal叫hive/[email protected]，实例名就是主机名
CDH默认不在所有hive的gateway生成hive.keybab，只在HS2所在节点生成，所以如果想要在client访问hive，要自己生成hive.keytab
hive的keytab只在node105有，hdfs的3个都有

1.hive

自己在node106创建1个hive/[email protected]。

然后登录beeline -u "jdbc:hive2://node105:10000/;principal=hive/[email protected]"

生成后，没kinit时
在这里插入图片描述
kinit后 kinit hive/hive，

2.hdfs

没kinit时，无法访问hdfs
在这里插入图片描述
找到CDH生成的hdfs.keytab，然后认证

就可以访问了

3.测试Spark&Hive程序在类公司的kerberos环境中运行

须知：

一般一个集群就1个realm

3.1 添加node107 spark的principal，CDH自动在node106生成了1个

在这里插入图片描述

3.2 在node107生成spark的keytab到/opt/keytab_gbicc/spark.keytab

在这里插入图片描述

3.3 没给cdh5实例授权的情况下执行spark程序

spark2-submit --master yarn --deploy-mode client
–class com.cib.dqms.SparkWithPMMLAndDQMS
/opt/test/spark_pmml_dqms-shade-1.0-SNAPSHOT.jar
/user/spark/test.pmml dctest.test 1 result

在这里插入图片描述

3.4 给cdh5实例授权的情况下执行spark程序

kinit -kt /opt/keytab_gbicc/spark.keytab spark/cdh5
klist

九、用java程序进行kerberos验证

kerberos的认证是以url为单位的，只要这个url认证过，之后只要再访问这个url，都可以通过。
java程序访问组件需要建立连接，其实也是通过url。java程序运行在linux上时，猜测应该是java自己有1个kerberos的客户端，跟linux本地的客户端不同，所以java程序不仅需要指定principal和keytab这2个认证必须的，连客户端需要的krb5.conf都需要提供。
在这里插入图片描述

须知

公司的krb5.conf在/opt下，keytab在/opt/keytab_gbicc，principal格式：用户名/[email protected]
-

十、问题

1.同时2个缓存，用哪个？

前后认证了2个principal，发现klist缓存中只有1个最新的，同时只能由1个认证？

zdkdchao

发布了21 篇原创文章 · 获赞 0 · 访问量 626

私信关注

kerberos初步学习

一、What is Kerberos?

二、What problem did it solved？

三、理解

1.架构、角色设计

2.角色

2.1 KDC：3大组件。也就是kerberos的server

2.2 client：所有需要认证的模块，不仅仅是节点，也可能是进程

2.3 Realm：就是由KDC和kerberos客户端组成的网络。是principal命名空间的一部分。

2.4 principal：用户或服务的唯一标识，用户和服务都需要认证。是唯一标识，3层结构：realm/实例/用户名

syntax格式：主名称/实例名@领域名

2.5 TGT：ticket for getting tickets，ticket有2种，TGT和server ticket

2.6 keytab：包含一个或多个principal及其密码的文件，keytab + principal可以完成认证

3.认证原理

须知：

1.不用kerberos时，登录哪个服务，哪个服务认证就行了。现在引入了1个第三方，第三方认证通过了，怎么让服务知道？

四、

五、在apache中安装配置kerberos

1.安装

1.1 server节点安装，server节点就是KDC节点

1.2 client节点和server节点都安装

2.配置kerberos

2.1 server的kdc.conf

须知：

2.2 client的krb5.conf

须知：

配完要分发：[root@node105 ~]# rrsync /etc/krb5.conf

2.3 创建数据库

2.4 启动kerberos的Server

注意：

六、在apache中操作kerberos

1.注册，就是在数据库中创建principal，通过操作kerberos数据库完成

1.1 登录kerberos数据库

{1} 本地登录（无需认证），在KDC本地登录

{2} 远程登录（server需启动kadmin服务），kadmin.local要改为kadmin

1.2 创建principal，就是注册

1.2 修改principal密码

1.3 查看所有principal

2.认证

2.1 密码认证

{1} kinit命令

2.2 keytab密钥文件认证

{1} 生成主体admin/admin的keytab文件到指定目录/root/admin.keytab

{2} 使用kinit -kt + keytab进行认证

{3} 查看、销毁认证凭证

七、在CDH中配置kerberos

1.手动完成kerberos的安装配置，也就是 五 中的操作

2.为admin实例赋予所有权限

注意：设完权限要重启krb5kdc和kadmin

3.为CM创建管理员主体/实例，因为cm要通过所有组件的认证，所有要创建对应的principal

4.CM-UI中启动kerberos

4.1 启动所有服务，下拉箭头-启动kerberos

注意：此处我因为之前设置/var/kerberos/krb5kdc/kadm5.acl没重启，导致创建principal时失败，此时重启后可以在管理-安全-凭证中重新生成

5.1 客户端访问服务

须知：

kafka

浏览器认证HDFS WebUI

5.2 服务之间

flume - kafka - hdfs

5.3 脚本中：

5.4

八、测试

须知：

1.hive

2.hdfs

3.测试Spark&Hive程序在类公司的kerberos环境中运行

须知：

3.1 添加node107 spark的principal，CDH自动在node106生成了1个

3.2 在node107生成spark的keytab到/opt/keytab_gbicc/spark.keytab

3.3 没给cdh5实例授权的情况下执行spark程序

3.4 给cdh5实例授权的情况下执行spark程序

九、用java程序进行kerberos验证

须知

十、问题

1.同时2个缓存，用哪个？

猜你喜欢

配完要分发：`[root@node105 ~]# rrsync /etc/krb5.conf`

1.手动完成kerberos的安装配置，也就是 `五` 中的操作

`注意：设完权限要重启krb5kdc和kadmin`