Spark 框架安全认证实现

Posted 2023-03-09

参考技术A

随着大数据集群的使用，大数据的安全受到越来越多的关注一个安全的大数据集群的使用，运维必普通的集群更为复杂。
集群的安全通常基于kerberos集群完成安全认证。kerberos基本原理可参考 ：一张图了解Kerberos访问流程

Spark应用(On Yarn模式下)在安全的hadoop集群下的访问，需要访问各种各样的组件/进程，如ResourceManager，NodeManager，NameNode，DataNode,Kafka,Hmaster,HregionServer，MetaStore等等。尤其是在长时运行的应用，如sparkStreaming，StructedStreaming，如何保证用户认证后的长期有效性，其安全/认证更为复杂。

一个Spark应用提交用户要先在kdc中完成用户的认证，及拿到对应service服务的票据之后才能访问对应的服务。由于Spark应用运行时涉及yarnclient，driver，applicationMaster，executor等多个服务，这其中每个进程都应当是同一个用户启动并运行，这就涉及到多个进程中使用同一个用户的票据来对各种服务进行访问，本文基于Spark2.3对此做简要分析。

spark应用的提交用户认证之后才能提交应用，所以在yarnclient/driver的逻辑中必然会执行到kerberos认证相关的登录认证。然而其他的进程如applicationMaster，executor等均需要经过认证，应用提交后才由用户启动，这些进程则可以不进行kerberos认证而是利用Hadoop的token机制完成认证，减小kerberos服务压力，同时提高访问效率。

Hadoop的token实现基类为org.apache.hadoop.security.token.Token，

不同的服务也可hadoop的token来交互，只要使用不同的identifer来区分token即可。 如NMTokenIdentifier, AMRMTokenIdentifier,AuthenticationTokenIdentifier等不同的tokenIdentifier来区分不同的服务类型的token。

此处yarnclient指的是向ResourceManager提交yarn应用的客户端。在spark中，向yarn提交应用有两种应用有yarn-client,yarn-cluster模式。在这两种应用模式下提交应用，yarn client逻辑有些许不同。

安全hadoop场景下spark的用户登录认证机制

在client的submitApplication方法中提交app，之后创建amContext，准备本地资源，此时会将本地的文件上传至HDFS，其中就包括keytab文件，同时会生成 spark_conf .properties配置文件以供am使用，该配置文件中会包含keytab的配置

其中的amKeytabFileName是在setUpCredentials时设置如下，该值为指定的keytab文件加上随机的字符串后缀，骑在am重点使用，可参考下节的介绍。

获取相关组件的token，注意：此处的token均非与yarn服务交互相关token，这里只有与HDFS，HBASE，Hive服务交互的token。

Spark中常访问的服务使用token机制的有hive，hbase，hdfs，对应的tokenProvider如下：

以HbaseDelegationTokenProvider为例，主要是通过反射调用hbase的TokenUtil类的obtainTOken方法，对应的obtainDelegationTokens方法如下：

PS ： HBase的token获取的用户需要具有hbase:meta表的exec权限，否则无法成功获取token

在获取token后，将token设置到amContainer中，并放入appContext中

在yarn-client模式下，driver在yarnclient进程中启动，同样需要访问业务层及集群的相关组件如hdfs。driver通过读取am更新在hdfs路径下的credentials文件来保证driver节点的token有效。

在yarn-cluster模式下，driver运行在applicationMaster的JVM中，其安全相关由Am同一操作

applicationMaster是Yarn进行应用调度/管理的核心，需要与RM/NM等进行交互以便应用运行。其中相关的交互均通过token完成认证，认证实现由Yarn内部框架完成。查看am日志发现，即是在非安全（非kerberos）的场景下，同样会使用到token。而与hdfs，hbase等服务交互使用的token则需Spark框架来实现。

在ResourceManager接收到应用提交的ApplicationSubmissionContext后，在其AmLauncher.java的run方法中为am设置生成“YARN_AM_RM_TOKEN，该token用于am于rm通信使用”

Am在启动之后，会向ResourceManager申请container，并与对应的NodeManager通信以启动container。然而AM与NM通信的token是如何得到的呢？

查看AMRMClientImpl类可以看到，AM向RM发送分配请求，RM接收到请求后，将container要分配至的NM节点的Token放置response中返回给AM。Am接收到response后，会保存NMToken，并判定是否需要更新YARN_AM_RM_TOKEN

RM通过ApplicationMasterService响应allocation请求

AM在准备启动container时，将当前用户的token都设置进ContainerLaunchContext中

查看Am启动命令大致如下，可以发现有指定配置文件，而该配置文件即为yarnclient生成上传至hdfs，在am启动前由NodeManager从hdfs中copy至本地路径，供container使用：

查看此配置文件可以看到有如下配置项：

下图为am进程使用到的资源文件

如上可以看出，am虽然运行在集群中，但运行时认证相关的资源已经准备就绪。下面分析其运行中关于安全的逻辑

在applicationMaster中，定期更新token，并写入文件到hdfs的相关目录，并清理旧文件以供各executor使用。
在ApplicationMaster启动后，进行login登录并启动名为am-kerberos-renewer的dameon线程定期登录，保证用户认证的有效性

private val ugi =
val original = UserGroupInformation.getCurrentUser()

在am中启动AMCredentialRenewerStarter线程,调度认证登录及token renew逻辑

在scheduleLoginFromKeytab中，会周期调度登录，token获取更新写入hdfs文件等操作。
其核心逻辑如下

调度周期：

调度流程：

executor的认证同样使用的是token机制。executor启动之后，根据driver启动设置的$spark.yarn.credentials.file启动token更新：

Executor中的token更新是读取hdfs目录 timeStamp-$nextSuffix目录下的文件，读取到缓存中，以便保证读取到的是更新后的token使用。

Spark框架完成的kerberos认证及使用token与其他服务交互的机制使用较为简单，只需要在提交应用时的spark-submit命令行中加入--principal appuserName --keytab /path/to/user.keytab即可