就是假设 Hadoop 使用了 Kerberos 验证，且 Yarn 使用 LinuxContainerExecutor，那么当 NM 以提交 Job 的用户身份启动 Container 时，当前 Container 进程需要进行 Kerberos 验证 么？
如果需要的话，它是 NM 的 keytab 进行验证呢，还是 Job 提交者 keytab 需要安装到所有 NM host 节点上？
你这个是个原理问题吧？如果cm启用kerberos，你提交作业其实不用管这些的呢。
嗯，是想把底层原理搞清楚；我们之前没上 Kerberos，计划要上，梳理过程中发现这个点有疑惑
比如 Hadoop 内部用户，hdfs、yarn、hive 这些都会在 Kerberos 中创建以及 keytab 分发到相应节点了，验证自然可以完成
而数据平台上层有很多用户，A/B/C/X...，这些用户提交的任务再 NM 节点上运行时，是怎么验证的呢？感觉如果也要把他们的 keytab 都分发到 NM 上那操作有点复杂了
你的问题其实就是在开启kerberos的环境中，用户提交作业后，用户跟集群里的服务是怎么认证交互的。主要是delegation token来解决这个问题的，跟A/B/C/X等用户的keytab已经没啥关系了，后面都是靠token来交互的。
https://blog.cloudera.com/hadoop-delegation-tokens-explained/
你可以参考一下关于token的介绍文档
1，在 Hive 中是建议关闭用户代理的，所有用户提交查询时 hiveserver2 先进行权限检查，通过之后以 hive 的用户身份提交 job 到 hadoop 中
2，另外还建议把 HDFS warehouse 路径的用户和组都设置为 hive，这样查询的 job 任务也只能有 hive 用户读写，整个数仓权限都统一由 hive 控制了
如果这样的话，其它 SQL 引擎（如 sparksql、presto、impala 等）上跑的 hive 仓库 任务，该以什么用户身份执行呢？
Impala，提交的所有任务是以impala用户执行的，
a)如果是Sentry，而impala用户属于hive组，Hive仓库hive 组的是都有读写权限的，Sentry是RBAC模型，hive用户组一般都是放到admin这个role里的，相当于超级用户
b)如果是Ranger，Ranger时候ABAC模型，一般都是以user为单位设置权限，impala和hive用户一般都是设置到了所有database和所有table都有权限读写，也相当于是超级用户
SparkSQL作业是真实用户，
a)如果是Sentry，因为Sentry默认有HDFS ACL同步，只要在sentry中为执行作业的用户赋了hive表权限即可。
b)如果是Ranger，需要为执行作业的用户赋权hive表对应HDFS目录的权限，同时需要为该用户设置Hive表的权限，直接在Ranger中界面化设置即可。Ranger有新特性，RMS服务用来做HDFS ACL同步，但还是属于技术预览版，没那么成熟。
Presto与Spark SQL情况一样。
假设以 ranger 作为授权管理，对以上 sql 引擎提交任务用户授权 hdfs warehouse 路径，那么这些这些用户写入的数据文件用户属组就是实际用户而不是 hive；
这跟上面的建议就矛盾了
不矛盾，我在上面已经回答了，不管是sentry还是ranger，这三个组件执行作业的用户是同样的原理。