Kerberos安装配置
https://www.psvmc.cn/article/2022-11-08-bigdata-kerberos-centos.html
Java显示调试日志
1 | -Dsun.security.krb5.debug=true -Djava.security.auth.login.config=/data/hadoop/etc/hadoop/hdfs.conf -Djava.security.krb5.conf=/etc/krb5.conf |
服务器上测试
Flink任务认证
flink on yarn
1 | flink run \ |
认证原理
- flink程序启动,自动将keytab文件自动上传hdfs,由yarn管理,分发给每个executor缓存token,定时刷新。
- 基于以上原理,当自定义RichSinkFunction里需要是使用基于kerberos认证的组件时,不需要再做认证操作。
- 比如:hive、hbase、kudu等等,直接建立连接就可以访问
服务上用户认证
认证
1 | kinit -kt /data/tools/bigdata/kerberos/hdfs.keytab hdfs/hadoop01@HADOOP.COM |
查看认证状态
1 | klist |
Hive认证连接
在服务器上测试
1 | hive |
使用JDBC
之前
1 | beeline -n hive -u jdbc:hive2://hadoop01:10000/default |
注意一定要添加双引号,否则无效
配置中设置的
1 | beeline -n hive -u "jdbc:hive2://hadoop01:10000/zdb;principal=hdfs/hadoop01@HADOOP.COM" |
目前测试的只能使用配置文件中设置的用户才能连接。
查询
1 | show databases; |
Hbase连接
1 | hbase shell |
Phoenix Shell连接
启动 Zookeeper => HDFS => Yarn => HBase 后
1 | sqlline.py hadoop01,hadoop02,hadoop03:2181 |
第一次启动比较慢,请耐心等待。
查询
1 | !tables |
Hive JDBC认证
需要两个文件
配置文件
krb5.conf
认证文件
krb5.keytab
,一般由服务器生成后获取
放到resources
目录下
Kerberos认证
指定krb5配置文件:krb5.conf,根据实际情况替换
认证文件:krb5.keytab,根据实际情况替换
认证用户:hive,根据实际情况修改
这里是通过将配置文件和认证文件拷贝到临时目录进行认证,可以根据需要指定固定目录认证
使用项目中的配置
认证方法KerberosAuth.java
1 | import org.apache.hadoop.conf.Configuration; |
使用服务器上的配置
1 | import org.apache.hadoop.conf.Configuration; |
JDBC工具类
Hive中配置Kerberos认证后,JDBC连接要进行kerberos认证。
认证后JDBC的URL也要添加认证相关的配置
如下
1 | jdbc:hive2://192.168.7.101:10000/zdb;principal=psvmc/hadoop@HADOOP.COM |
其中
principal:
hive 用户名
hostname:主机名,也可以理解为组
PSVMC.CN:realms和krb5.conf文件里一致即可
工具类
1 | import com.gientech.schedule.config.KerberosConnect; |
工具类
异常类
1 | public class ZRuntimeException extends RuntimeException { |
读取配置类
1 | import org.apache.hadoop.conf.Configuration; |
测试类
1 | import java.io.IOException; |
测试Phoenix
1 | public static void testPhoenix(String principal, String keytabPath) throws IOException, ClassNotFoundException, SQLException { |
总结
首先在配置的时候注意一下几个环境变量的设置
- ZK_HOME
- HADOOP_HOME
- HBASE_HOME
ZK直接使用的配置文件认证。
jaas.conf
1 | Server { |
HDFS、YARN、Hive、Hbase都使用Hadoop的认证。
Phoenix使用胖客户端形式,自身认证。
概念
Principal 和 Ticket的关系?
Principal 和 Ticket 是 Kerberos 中的两个概念,它们之间存在一定的关系。
Principal(主体):Principal 是 Kerberos 中标识用户或服务的实体。它通常是一个唯一的标识符,如用户名、服务名或主机名,用于识别实体的身份。
Ticket(票据):Ticket 是 Kerberos 认证系统中的凭证,用于表示一个已经通过身份验证的实体拥有权限访问某个服务。Ticket 包含了用户或服务的身份信息以及被授权的服务和权限。
Principal 可以被转换成 Ticket,这是通过 Kerberos 的身份验证过程实现的。当一个用户进行 Kerberos 认证成功后,会得到一个包含用户身份信息和访问权限的 Ticket。这个 Ticket 在用户访问受保护资源的时候,将被用于证明用户的身份和授权。
因此,Principal 是用户或服务的标识,而 Ticket 是用户经过 Kerberos 认证后获得的具有访问权限的凭证。Ticket 将被用于用户与服务之间的通信,以验证用户的身份并授权其访问相应的资源。
相同用户同一个Principal多次登录会产生不同的Ticket吗?
是的,同一个 Principal 多次登录会产生不同的 Ticket。
在 Kerberos 认证中,Ticket 是基于时间戳和会话标识生成的,并且每个票据都是独立的。
每次用户进行 Kerberos 认证时,会生成一个新的票据,该票据包含了用户的身份信息和访问权限。
即使是同一个 Principal,不同的登录会话也会生成独立的票据。
这样做的目的是增加安全性和防止重放攻击。
这意味着每次用户登录后,会获得一个新的 Ticket,并且旧的 Ticket 将会失效。
新生成的 Ticket 将会在会话期限内(通常为一段时间)保持有效,并用于访问受保护的资源。
每个 Ticket 都有自己的唯一标识和有效期限,在过期后将不再被接受。
因此,同一个 Principal 多次登录会生成不同的 Ticket,每个 Ticket 对应一个独立的登录会话,并拥有自己的有效期限和访问权限。
注意
当用户进行新的登录并获得新的票据后,旧的票据将会失效,不再被服务器接受。
这样做是为了保证安全性,确保只有最新的有效票据被使用来授权用户访问资源。
测试
认证
1 | kinit -kt /data/kerberos/kerberos.keytab hdfs/hdp01@HADOOP.COM |
查看认证状态
1 | klist |