隨著大數據集群的使用，大數據的安全受到越來越多的關註壹個安全的大數據集群的使用，運維必普通的集群更為復雜。
集群的安全通常基於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即可