1.Kerberos身份验证在ChunJun中的源码落地实践
2.Hbase - kerberos认证异常
3.一篇文章彻底理解 HIVE 常见的三种 AUTHENTICATION 认证机制的配置与使用

Kerberos身份验证在ChunJun中的落地实践

       在古希腊神话中，Kerberos是源码一只三头犬，守护在地狱之门外，源码禁止人类进入。源码那么，源码在现实中，源码app的源码怎么运行Kerberos又是源码什么呢？

       Kerberos是一种计算机网络授权协议，用于在非安全网络中对个人通信进行安全的源码身份认证。它通过密钥加密技术为客户端/服务器应用程序提供身份验证，源码主要用在域环境下的源码身份验证。

       在以往，源码只有服务器的源码运维管理人员在配置Active Directory等东西时才会接触到Kerberos。但随着大数据的源码流行，整个Hadoop生态圈在安全方面对Kerberos的源码依赖性越来越强。同时，源码lldp源码解析由于Kerberos认证需要入侵式改造代码，使得越来越多的大数据开发人员开始接触Kerberos。

       目前，用于身份密码验证的方式主要面临两个问题：一是人工记忆的密码混乱且易遗忘，一些简单的密码又容易被攻击；二是技术错觉，在计算机上输入密码时显示的是一串星号，大家误以为很安全，实际上计算机通过网络发送密码基本是发送“明文”密码，大部分密码都处于“裸奔”状态。Kerberos的出现很好地解决了这个问题，它减少了每个用户在使用整个网络时必须记住的密码数量——只需记住Kerberos密码，同时Kerberos结合了加密和消息完整性来确保敏感的身份验证数据不会在网络上透明地发送。通过提供安全的身份验证机制，Kerberos为最终用户和管理员提供了明显的转售系统源码好处。

       principal是Kerberos世界的用户名，用于标识身份。每个用户都会有一个principal，如果principal失效或者不正确，那么这个用户将无法访问任何资源。principal主要由三部分构成：primary，instance（可选）和realm。

       primary是主体，每个principal都会有的组成部分，代表用户名（username）或服务名（service name）。instance用于服务主体以及用来创建用于管理的特殊主体。realm是认证管理域名，用来创建认证的边界。每个域都会有一个与之对应的薪火源码kdc服务用于提供域内的所有服务的认证服务。

       接下来我们来介绍一下ChunJun任务提交中的Kerberos认证。我们可以参考ChunJun的readme文档中的yarn session部分：

       github.com/DTStack/chun...

       首先，我们需要启动一个yarn session环境，进入Flink的bin目录下执行yarn-session脚本启动flink session并使用-t参数上传ChunJun的依赖包。

       当我们执行yarn-session时，脚本内部会调用java命令运行FlinkYarnSessionCli这个类的main方法。在FlinkYarnSessionCli的main方法中，首先需要安装一个全过程的安全配置，然后获得一个安装后的上下文，并且在上下文中运行run方法。

       在run方法中我们构建了一个YarnClusterDescripter对象，这个对象中封装了Flink所依赖的配置文件和jar包等。然后调用YarnClusterDescripter对象的DeploySessionClister方法将任务提交到yarn集群。至此完成了Flink session到Yarn的雾北源码一个提交。

       我们再回顾下整体的提交流程：

       ● Flink => HDFS

       Flink需要将配置文件以及session所依赖的jar上传至HDFS，因此需要与HDFS进行通信。

       ● Flink => Yarn

       Flink需要向Yarn申请资源，因此需要与Yarn进行通信。

       ● Flink => Zookeeper

       如果Flink配置了基于Zookeeper的高可用，那么JobManager需要在Zookeeper注册leader节点，客户端还需要从Zookeeper上的leader节点获取webMonitorUrl，因此需要与Zookeeper通信。

       接下来为大家介绍ChunJun Connector中的Kerberos认证。

       以ChunJun HDFS Connector为例，插件在openInputFormat方法中会对任务的目标数据源HDFS是否开启了Kerberos进行判断，如果开启了Kerberos，则会根据配置的认证文件进行认证并获取认证后的ugi，ugi可以认为是之后插件与HDFS通信的用户凭证，里面保存着用户的认证信息。

       对于每个算子实例来说，Kerberos认证只会进行一次（不包括认证过期后的刷新），因此Kerberos认证的代码应该在该方法中实现。

       一般来说，Hadoop生态中的数据源组件如HDFS、HBase、Hive等都是用ugi（UserGroupInformation）进行Kerberos认证。ChunJun内部也提供了相关的工具类用于获取登录后的ugi：com.dtstack.ChunJun.util.FileSystemUtil#getUGI。

       对于Zookeeper、Kafka等组件，开启Kerberos认证后，用户需要在插件端配置jaas.conf文件，再通过各个组件提供的参数配置项配置组件所选用的jaas.conf的entry，即可完成Kerberos配置。

       如何排查Kerberos认证问题，可以通过以下方法：

       $Flink_HOME/conf/Flink-conf.yaml

       #jvm启动参数中增加“-Dsun.security.krb5.debug=true”

       env.java.opts：用于配置启动所有Flink进程的JVM参数

       env.java.opts.jobmanager：用来配置启动JobManager的JVM参数

       env.java.opts.taskmanager：用来配置启动TaskManager的JVM参数

       env.java.opts.historyserver：用来配置启动HistoryServer的JVM参数

       env.java.opts.client：用来配置启动Flink Client的JVM参数

       Kerberos认证常见问题包括：

       1.javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]

       此消息表明一个操作尝试要求以Kerberos的user/host@realm身份认证的操作，但票据cache中没有用于user/host@realm的票据。

       2.javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Fail to create credential. () - No service creds)]

       由JDK缺陷引起

       3.Found unsupported keytype()

       确保正确安装了与JDK相匹配的无限强度策略文件的正确版本

       4.GSSException: No valid credentials provided (Mechanism level: Server not found in Kerberos database (7) - UNKNOWN_SERVER)

       hostname或要访问的URL与keytab中列出的主机之间发生主机名不匹配

Hbase - kerberos认证异常

       > 之前怎么认证都认证不上，问题找了好了，发现它的异常跟实际操作根本就对不上，死马当活马医，当时也是瞎改才好的，给大家伙记录记录。

        ```

        KrbException: Server not found in Kerberos database (7) - LOOKING_UP_SERVER

        >>> KdcAccessibility: remove storm1.starsriver.cn

        at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:)

        >>> KDCRep: init() encoding tag is req type is

        at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:)

        >>>KRBError:

        at sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:)

        cTime is Fri Aug :: CST

        sTime is Tue Jul :: CST

        at sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:)

        suSec is

        error code is 7

        at sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:)

        error Message is Server not found in Kerberos database

        at sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:)

        cname is hbase/lake.dounine.com@dounine.com

        at sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:)

        sname is hbase/...@dounine.com

        msgType is

        at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:)

        at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:)

        at com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:)

        at org.apache.hadoop.hbase.security.AbstractHBaseSaslRpcClient.getInitialResponse(AbstractHBaseSaslRpcClient.java:)

        at org.apache.hadoop.hbase.security.NettyHBaseSaslRpcClientHandler$1.run(NettyHBaseSaslRpcClientHandler.java:)

        at org.apache.hadoop.hbase.security.NettyHBaseSaslRpcClientHandler$1.run(NettyHBaseSaslRpcClientHandler.java:)

        at java.security.AccessController.doPrivileged(Native Method)

        at javax.security.auth.Subject.doAs(Subject.java:)

        at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:)

        at org.apache.hadoop.hbase.security.NettyHBaseSaslRpcClientHandler.handlerAdded(NettyHBaseSaslRpcClientHandler.java:)

        at org.apache.hbase.thirdparty.io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:)

        at org.apache.hbase.thirdparty.io.netty.channel.DefaultChannelPipeline.addFirst(DefaultChannelPipeline.java:)

        at org.apache.hbase.thirdparty.io.netty.channel.DefaultChannelPipeline.addFirst(DefaultChannelPipeline.java:)

        at org.apache.hbase.thirdparty.io.netty.channel.DefaultChannelPipeline.addFirst(DefaultChannelPipeline.java:)

        at org.apache.hadoop.hbase.ipc.NettyRpcConnection.saslNegotiate(NettyRpcConnection.java:)

        at org.apache.hadoop.hbase.ipc.NettyRpcConnection.access$(NettyRpcConnection.java:)

        at org.apache.hadoop.hbase.ipc.NettyRpcConnection$3.operationComplete(NettyRpcConnection.java:)

        at org.apache.hadoop.hbase.ipc.NettyRpcConnection$3.operationComplete(NettyRpcConnection.java:)

        at org.apache.hbase.thirdparty.io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:)

        at org.apache.hbase.thirdparty.io.netty.util.concurrent.DefaultPromise.notifyListeners0(DefaultPromise.java:)

        at org.apache.hbase.thirdparty.io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:)

        at org.apache.hbase.thirdparty.io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:)

        at org.apache.hbase.thirdparty.io.netty.util.concurrent.DefaultPromise.trySuccess(DefaultPromise.java:)

        at org.apache.hbase.thirdparty.io.netty.channel.DefaultChannelPromise.trySuccess(DefaultChannelPromise.java:)

        at org.apache.hbase.thirdparty.io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.fulfillConnectPromise(AbstractNioChannel.java:)

        at org.apache.hbase.thirdparty.io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:)

        at org.apache.hbase.thirdparty.io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:)

        at org.apache.hbase.thirdparty.io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:)

        at org.apache.hbase.thirdparty.io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:)

        at org.apache.hbase.thirdparty.io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:)

        at org.apache.hbase.thirdparty.io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:)

        at org.apache.hbase.thirdparty.io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:)

        at java.lang.Thread.run(Thread.java:)

        Caused by: KrbException: Identifier doesn't match expected value ()

        at sun.security.krb5.internal.KDCRep.init(KDCRep.java:)

        at sun.security.krb5.internal.TGSRep.init(TGSRep.java:)

        at sun.security.krb5.internal.TGSRep.<init>(TGSRep.java:)

        at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:)

        ... more

        ```

        此错误需要将线上服务器的域名映射放入Client中的`/etc/hosts`

        ```

        ..0.2 h1.demo.com

        ..0.3 h2.demo.com

        ..0.4 h3.demo.com

        ```

        ---

        

一篇文章彻底理解 HIVE 常见的三种 AUTHENTICATION 认证机制的配置与使用

       大家好，我是明哥！

       本片博文，分享下 HIVE 常见的三种 AUTHENTICATION 认证机制，包括其配置与使用。

       数据安全是企业的重要议题，涉及误删除、误修改、越权使用和不慎泄露等风险。通过制定严格的数据使用规范和应用数据安全技术，确保数据的安全使用。安全概念包含三个核心领域：认证（Authentication）、鉴权（Authorization）和审计（Audit），以及加密（Encryption）。

       HIVE 的认证机制通过服务端参数 hive.server2.authentication 配置，支持多种方式。常见使用的有三种：

       1. **客户端认证**：无论是专用CLI客户端、通用JDBC GUI客户端，还是Java应用（基于JDBC），都需要根据服务端配置的认证方式，使用相应方式认证后，才能成功连接 Hiveserver2，并提交查询命令。

       2. **无认证模式**：配置为 `hive.server2.authentication = none`，意味着不进行用户身份验证。

       3. **LDAP认证**：配置为 `hive.server2.authentication = ldap`，使用轻目录访问协议（Lightweight Directory Access Protocol）进行认证。

       4. **Kerberos认证**：配置为 `hive.server2.authentication = kerberos`，在启用了 Kerberos 安全认证的大数据集群环境中，使用此方式确保安全连接。

       在Kerberos环境下，HIVE的认证方式具体如下：

       **Kerberos认证**：配置为 `hive.server2.authentication = kerberos`。

       **LDAP认证**：配置为 `hive.server2.authentication = ldap`。

       在CDH、TDH、CDP与TDH中，HIVE认证方式存在差异。

       总结：在实际应用中，选择合适的认证机制，根据环境配置参数，确保数据安全与高效访问。通过合理的配置，实现数据安全的多层防护。