Flink on Yarn with Kerberos

Flink作为新一代的大数据处理引擎，其批流一体化的设计与出色的流处理性能，在业界得到了很多头部公司的青睐。目前运行Flink的集群多采用Yarn进行资源管理，这是成熟的方案。Yarn做为Hadoop生态系统中的工具之一，客户端通常需要经过Kerberos认证才能使用Yarn提交或管理任务。那么Flink任务是如何提交到带有Kerberos认证的Yarn集群的呢？我们先从Kerberos的原理开始说起，再说如何让Flink在带有Kerberos认证的Yarn集群上跑起来，知其然知其所以然。

为什么需要Kerberos

在Hadoop1.0.0或者CDH3以前，Hadoop集群中的所有节点几乎就是裸奔的，主要存在以下安全问题：

• NameNode与JobTracker上没有用户认证，用户可以伪装成管理员入侵到一个HDFS 或者MapReduce集群上。
• DataNode上没有认证：Datanode对读入输出并没有认证，如果知道block的ID，就可以任意的访问DataNode上block的数据
• JobTracker上没有认证：可以任意的杀死或更改用户的jobs，也可以更改JobTracker的工作状态
• 没有对DataNode与TaskTracker的认证：用户可以伪装成DataNode与TaskTracker，去接受JobTracker与Namenode的任务指派。

为了解决这些问题，kerberos认证出现了，它实现的是机器级别的安全认证。

其原理是事先将集群中的机器添加到kerberos数据库中，在数据库中分别产生主机与各个节点的keytab，并将这些keytab分发到对应的节点上。通过这些keytab文件，节点可以从数据库中获得与目标节点通信的密钥防止身份被冒充。针对Hadoop集群可以解决两方面的认证

• 解决服务器到服务器的认证，确保不会冒充服务器的情况。集群中的机器都是是可靠的，有效防止了用户伪装成Datanode，Tasktracker，去接受JobTracker，Namenode的任务指派。
• 解决client到服务器的认证，防止用户恶意冒充client提交作业，也无法发送对于作业的操作到JobTracker上，即使知道datanode的相关信息，也无法读取HDFS上的数据。

对于具体到用户粒度上的权限控制，如哪些用户可以提交某种类型的作业，哪些用户不能，目前Kerberos还没有实现，需要有专门的ACL模块进行把控。

Kerberos认证过程

Kerberos认证过程会涉及以下几个基本概念：

• Principal(安全个体)：被认证的个体，有一个名字和口令，每个server都对应一个principal，其格式如下，@前面部分为具体身份，后面的部分称为REALM。

component1 / component2 @ REALM