我正在尝试弄清楚在共享群集上运行spark作业时如何强制执行安全性。我理解如何确保未经授权的节点无法加入群集（设置共享密钥kerberos auth）以及如何限制谁可以提交作业（在纱线下运行然后使用游侠来限制谁可以访问每个队列）。但是，我正在努力理解如何限制访问spark工作所需的资源。
如果我理解正确，工作节点上的所有Spark进程都将作为spark用户运行。据推测，火花用户本身应具有非常小的权限，但是如果您的火花工作需要访问例如，那么问题就变成该怎么做了。 sql server。 The Spark security docs提到了一个密钥库。这是否意味着提交作业的用户可以使用spark-submit传递一个主体和keytab，可以用来对外部资源进行身份验证，就像提交者发出请求一样。
后续问题是安全文档还提到临时文件（随机文件等）未加密。这是否意味着您必须假设spark处理的任何数据都可能泄漏给您的spark群集的任何其他用户？如果可以的话，可以使用他们建议的解决方法（使用加密的分区来解决这个问题）来解决这个问题吗？我假设不是因为spark用户本身必须能够解密这些数据并且所有程序都以此用户身份运行....
答案 0 :(得分：1)
我试图弄清楚如何在运行时强制执行安全性 在共享群集上激活作业。我理解如何确保 未授权的节点无法加入群集（设置共享密钥 kerberos auth）以及如何限制谁可以提交工作（在 纱线，然后使用像游侠这样的东西限制谁可以访问 每个队列）。然而，我正在努力理解一个人可能会如何 限制访问spark作业所需的资源。
您使用YARN队列来执行此操作。每个队列可以具有可用于队列的最少量资源。因此，您可以定义队列ACL以确保只有受信任的用户才能提交到队列并定义此队列将具有的最少资源量。
如果我理解正确，那么工作节点上的所有Spark进程都会 作为spark用户运行。
您的理解不准确。启用Kerberos（这是任何安全性讨论的前提条件）Spark作业将作为启动它们的Kerberos用户执行。有一个重要的警告 - Kerberos用户名必须与操作系统用户名匹配。
据推测，火花用户本身应该拥有 非常小的权限，然后问题变成了什么 如果您的火花工作需要访问，例如sql server。火花 安全文档提到了一个密钥库。这是否意味着用户 提交作业可以通过主体和keytab传递 spark-submit，可用于与外部进行身份验证 资源就好像提交者提出请求一样。
此密钥库用于不同且非常特定的目的 - 支持HTTP通信的TLS加密（例如Spark UI）。因此，您不能将其用作访问第三方系统的秘密存储。总的来说，在Hadoop基础架构中，无法与作业共享凭据。因此，每次都应该重新发明机制。由于作业将在代表启动它们的用户的操作系统级别上执行，因此您可以依靠操作系统控制将凭据分发给第三方资源（例如文件系统权限）。
后续问题是安全文档也提到了这一点 临时文件（随机文件等）未加密。这是什么意思 你不得不假设spark处理的任何数据都可能 可能泄露给你的火花星团的任何其他用户？如果是的话 可以使用他们提出的解决方法（使用加密的 这个数据的分区）来解决这个问题？我假设不是火花 用户本身必须能够解密此数据和所有数据 程序以此用户身份运行....
有几点需要注意。首先，如前所述，Kerberized-cluster上的Spark作业将作为启动作业的用户执行。作业生成的所有临时文件都具有文件系统权限，该权限仅授予对特定用户和纱线组的访问权限（仅包括纱线用户）。其次，磁盘加密可以保护您免受磁盘被盗，但永远不会保证操作系统级攻击的安全性。第三，从Spark 2.1开始，可以使用临时文件加密。
如果您有兴趣更深入地了解Spark-on-YARN安全模型，我建议您阅读Apache Spark on YARN Security Model Analysis（免责声明我是作者）。