Hadoop 迁移安全指南

Last reviewed 2024-04-17 UTC

Dataproc 和 Google Cloud 包含若干有助于保护数据安全的功能。本指南介绍了 Hadoop 的安全原理及其如何对应到 Google Cloud，并提供了在 Google Cloud 上部署该模型时设计安全性架构的相关指导。

概览

Hadoop 本地部署的典型安全模型和机制与云端安全模型和机制不同。 了解 Hadoop 上的安全性有助于您在将它部署到 Google Cloud 上时更好地搭建安全性架构。

您可以通过以下两种方式在 Google Cloud 上部署 Hadoop：作为 Google 代管的集群 (Dataproc)；或作为用户管理的集群（Compute Engine 上的 Hadoop）。本指南中的大多数内容和技术指南均同时适用于这两种部署形式。本指南在提及适用于任一部署类型的概念或过程时会使用 Dataproc/Hadoop 一词。在少数情况下，以 Dataproc 形式部署不同于以 Compute Engine 上的 Hadoop 形式部署，本指南会指出这些情况。

典型的本地 Hadoop 安全架构

下图显示了典型的本地 Hadoop 基础架构以及这种架构确保安全性的方式。请注意 Hadoop 基本组件彼此交互以及与用户管理系统交互的方式。

Hadoop 基础架构显示用户空间、安全边界和已实现 Hadoop 安全的单独框

总的来说，Hadoop 安全基于以下四个核心过程构建：

  • 身份验证，通过 Kerberos 与 LDAP 或 Active Directory 的集成提供
  • 授权，通过 HDFS 和 Apache Sentry 或 Apache Ranger 等安全产品提供，可确保用户拥有 Hadoop 资源的适当访问权限。
  • 加密，通过网络加密和 HDFS 加密提供，两者共同确保传输中的数据和静态数据的安全性。
  • 审核，由供应商提供的产品（例如 Cloudera Navigator）提供。

从用户账号的角度来看，Hadoop 有自己的用户和组结构，可用于管理身份和运行守护进程。例如，Hadoop HDFS 和 YARN 守护程序以 Unix 用户 hdfshdfs 和 yarn 的身份运行hdfs，如安全模式下的 Hadoop 中所述。

Hadoop 用户通常是与 Linux 系统用户或 Active Directory/LDAP 用户对应的。Active Directory 用户和群组由 Centrify 或 RedHat SSSD 等工具同步。

Hadoop 本地身份验证

安全的系统要求用户和服务向系统证明自己的身份。 Hadoop 安全模式使用 Kerberos 进行身份验证。 大多数 Hadoop 组件都支持使用 Kerberos 进行身份验证。Kerberos 通常在企业身份验证系统（例如 Active Directory 或 LDAP 兼容系统）内实施。

Kerberos 主体

Kerberos 中的用户称为“主体”。在 Hadoop 部署中，主体分为用户主体和服务主体两种。用户主体通常从 Active Directory 或其他用户管理系统同步到密钥分发中心 (KDC)。一个用户主体代表一个自然人用户。 一个服务主体与一个服务器的一项服务是一一对应关系，因此每个服务器上的每项服务都对应唯一的一个主体。

Keytab 文件

keytab 文件包含 Kerberos 主体及其密钥。用户和服务可以使用 keytab 对 Hadoop 服务进行身份验证，无需使用交互式工具并输入密码。Hadoop 会为每个节点上的每项服务创建服务主体。这些主体存储在 Hadoop 节点上的 keytab 文件中。

SPNEGO

如果使用网络浏览器访问 Kerberos 化的集群，则该浏览器必须知道如何传递 Kerberos 密钥。这就是 SPNEGO（SPNEGO）的用武之地，它提供了一种在 Web 应用中使用 Kerberos 的方法。

集成

Hadoop 与 Kerberos 集成后不仅可用于用户身份验证，还可用于服务身份验证。任何节点上的任何 Hadoop 服务都将拥有自己的 Kerberos 主体，可用于进行身份验证。服务通常具有存储在服务器上的 keytab 文件，其中包含一个随机密码。

为了能够与服务进行交互，真人用户通常需要通过 kinit 命令或 Centrify 或 SSSD 获取自己的 Kerberos 票据。

Hadoop 本地授权

用户或服务的身份通过验证后，授权系统会检查用户或服务的访问权限类型。在 Hadoop 上，一些开源项目（例如 Apache Sentry 和 Apache Ranger）可用于提供授权。

Apache Sentry 和 Apache Ranger

Apache Sentry 和 Apache Ranger 是 Hadoop 集群上常用的授权机制。Hadoop 上的组件可将各自的插件应用到 Sentry 或 Ranger，以指定 Sentry 或 Ranger 针对某个身份确认或拒绝访问权限时的行为方式。Sentry 和 Ranger 依赖于 Kerberos、LDAP 或 AD 等身份验证系统。Hadoop 中的组映射机制能确保 Sentry 或 Ranger 与 Hadoop 生态系统的其他组件使用相同的组映射。

HDFS 权限和 ACL

HDFS 使用类似 POSIX 的权限系统和访问控制列表 (ACL) 来确定用户是否拥有文件访问权限。每个文件和目录都与一个所有者和一个组相关联。该结构具有根文件夹，归超级用户所有。结构的不同级别可采用不同的加密方式，具有不同的所有权、权限和扩展 ACL (facl)。

如下图所示，权限通常在目录级别根据其访问需求授予特定组。访问模式被标识为不同的角色并对应各个 Active Directory 组。属于单个数据集的对象通常驻留在具有特定组权限的层，并包含不同数据类别的不同目录。

类似 POSIX 的 HDFS 文件夹结构

例如，stg 目录是财务数据的暂存区域。stg 文件夹具有 fin-loader 组的读写权限。在此暂存区域中，另一个应用账号组 fin-etl（表示 ETL 流水线）对此目录拥有只读访问权限。ETL 流水线处理数据并将其保存到要传送的 app 目录中。如需启用此访问模式，app 目录要拥有 fin-etl 组的读/写权限（该组为用于写入 ETL 数据的身份），拥有 fin-reader 组的只读权限（该组使用生成的数据）。

Hadoop 本地加密

Hadoop 提供多种方法用于加密静态数据和传输中数据。要加密静态数据的话，您可以使用基于 Java 的密钥加密或供应商提供的加密解决方案来加密 HDFS。HDFS 支持加密区域，可以提供使用不同密钥加密不同文件的功能。每个加密区域都与创建区域时指定的单个加密区域密钥相关联。

加密区域内的每个文件都有唯一的数据加密密钥 (DEK)。HDFS 绝不会直接处理 DEK。相反，HDFS 只处理加密的数据加密密钥 (EDEK)。客户端解密 EDEK，然后使用获得的 DEK 读取和写入数据。HDFS 数据节点只能看到加密字节流。

您可以使用传输层安全性 (TLS) 对 Hadoop 节点之间的数据传输进行加密。TLS 对 Hadoop 任何两个组件之间的通信中进行加密和身份验证。通常，Hadoop 会使用内部 CA 签名证书实现组件之间的 TLS。

Hadoop 本地审核

审核是安全的一大重要部分。审核可帮助您发现可疑活动，并提供拥有资源访问权限的用户记录。Hadoop 上的数据管理（例如审核跟踪）通常使用 Cloudera Navigator 和其他第三方工具来执行。这些工具可显示并控制 Hadoop 数据存储中的数据，并控制对这些数据所执行的计算。数据审核可以捕获系统中所有活动的不可变完整记录。

Google Cloud 上的 Hadoop

在传统的本地部署 Hadoop 环境中，Hadoop 安全的四个核心过程（身份验证、授权、加密和审核）由不同组件进行集成和处理。在 Google Cloud 上，这些过程由 Dataproc 和 Compute Engine 上的 Hadoop 外部的不同 Google Cloud 组件处理。

您可以使用 Google Cloud 控制台管理 Google Cloud 资源，该控制台是基于网页的界面。您还可以使用 Google Cloud CLI；如果您习惯使用命令行，则 Google Cloud CLI 可能更快、更方便。您可以通过在本地计算机上安装 gcloud CLI 或使用 Cloud Shell 实例来运行 gcloud 命令。

Hadoop Google Cloud 身份验证

Google Cloud 中有两种 Google 身份：服务账号和用户账号。大多数 Google API 都需要使用 Google 身份进行身份验证。少数 Google Cloud API 无需身份验证也可使用（使用 API 密钥），但我们建议将所有 API 与服务账号身份验证搭配使用。

服务账号使用私钥确认身份。用户账号使用 OAUTH 2.0 协议对最终用户进行身份验证。如需了解更多信息，请参阅身份验证概述。

Hadoop Google Cloud 授权

Google Cloud 提供多种方法来指定经过身份验证的身份对一系列资源所拥有的权限。

IAM

Google Cloud 提供 Identity and Access Management (IAM)，您可以通过定义哪些用户（主账号）拥有哪种资源的何种访问权限（角色），由此管理访问权限控制。

借助 IAM，您可以授予对 Google Cloud 资源的访问权限，并防止对其他资源进行不必要的访问。IAM 可让您实现最小权限安全原则，因此您只需授予对您的资源的最低必要访问权限即可。

服务账号

服务账号是一种特殊的 Google 账号，它属于您的应用或虚拟机 (VM)，不属于最终用户个人。应用可以使用服务账号凭据通过其他 Cloud API 验证自己的身份。此外，您还可以创建防火墙规则，按照分配给每个实例的服务账号来允许或拒绝传入和传出实例的流量。

Dataproc 集群是在 Compute Engine 虚拟机上构建的。在创建 Dataproc 集群时分配自定义服务账号会将该服务账号分配给集群中的所有虚拟机。这可让您的集群对 Google Cloud 资源进行精细访问和控制。如果您未指定服务账号，则 Dataproc 虚拟机将使用默认的 Google 管理的 Compute Engine 服务账号。默认情况下，此账号具有适用范围较广的项目编辑者角色，拥有多项权限。我们建议不要使用默认服务账号在生产环境中创建 Dataproc 集群。

服务账号权限

将自定义服务账号分配给 Dataproc/Hadoop 集群时，该服务账号的访问权限级别由授予集群虚拟机实例的访问权限范围和授予服务账号的 IAM 角色共同决定。要使用自定义服务账号设置实例，您需要同时配置访问权限范围和 IAM 角色。 从本质上讲，这些机制通过以下方式进行交互：

  • 访问权限范围授权实例拥有的访问权限。
  • IAM 根据授予实例所用服务账号的角色对访问权限进行限制。
  • 访问权限范围和 IAM 角色共有的权限便是实例拥有的最终权限。

在 Google Cloud 控制台中创建 Dataproc 集群或 Compute Engine 实例时，请选择实例的访问权限范围：

用于在 Google Cloud 控制台中设置范围的选项的屏幕截图

Dataproc 集群或 Compute Engine 实例定义了一组访问权限范围，可在允许默认访问权限设置中使用：

定义的访问权限范围列表

您可以从许多访问权限范围中进行选择。我们建议您在创建新的虚拟机实例或集群时，设置授予对所有 Cloud API 的完整访问权限（在控制台中）或 https://www.googleapis.com/auth/cloud-platform 访问权限范围（如果您使用 Google Cloud CLI）。这些范围授权访问所有 Google Cloud 服务。设置范围后，我们建议您通过将 IAM 角色分配给集群服务账号来限制该访问。

尽管存在 Google Cloud 访问权限范围，但该账号无法执行这些角色之外的任何操作。如需了解详情，请参阅服务账号权限文档。

将 IAM 与 Apache Sentry 和 Apache Ranger 进行比较

IAM 扮演类似于 Apache Sentry 和 Apache Ranger 的角色。 IAM 通过角色定义访问权限。对其他 Google Cloud 组件的访问权限在这些角色中进行了定义，并与服务账号相关联。这意味着使用相同服务账号的所有实例对其他 Google Cloud 资源的访问权限相同。有权访问这些实例的任何人对这些 Google Cloud 资源的访问权限与服务账号相同。

Dataproc 集群和 Compute Engine 实例没有将 Google 用户和组映射到 Linux 用户和组的机制。但是，您可以创建 Linux 用户和组。在 Dataproc 集群内部或 Compute Engine 虚拟机内部，HDFS 权限和 Hadoop 用户和组映射仍然有效。此映射可用于限制对 HDFS 的访问或使用 YARN 队列强制执行资源分配。

当 Dataproc 集群或 Compute Engine 虚拟机上的应用需要访问外部资源（例如 Cloud Storage 或 BigQuery）时，这些应用将以您分配给集群中虚拟机的服务账号的身份进行身份验证。然后，您可以使用 IAM 为您集群的自定义服务账号授予应用所需的最低访问级别。

Cloud Storage 权限

Dataproc 使用 Cloud Storage 作为其存储系统。Dataproc 还提供本地 HDFS 系统，但如果删除了 Dataproc 集群，HDFS 将不可用。如果应用不严格依赖 HDFS，最好使用 Cloud Storage 来充分利用 Google Cloud。

Cloud Storage 没有存储层次结构。目录结构模拟文件系统的结构。该存储系统也没有类似 POSIX 的权限。您可以在存储桶级别设置 IAM 用户账号和服务账号的访问权限控制。这么做不会根据 Linux 用户强制授权。

Hadoop Google Cloud 加密

除了少数例外情况之外，Google Cloud 服务使用多种加密方法对静态和传输中的客户内容进行加密。加密过程自动执行，无需客户执行任何操作。

例如，任何存储在永久性磁盘中的新数据均使用 256 位高级加密标准 (AES-256) 进行加密，而每个加密密钥本身会使用定期轮替的一组根（主）密钥进行加密。Google Cloud 使用的加密和密钥管理政策、加密库和信任根与 Google 的许多生产服务（包括 Gmail）和 Google 自己的公司数据所用的政策、库和信任根相同。

加密是 Google Cloud 的默认功能（与大多数本地 Hadoop 实现不同），除非您要使用自己的加密密钥，否则无需担心加密的实现。Google Cloud 还提供客户管理的加密密钥解决方案和客户提供的加密密钥解决方案。您可以根据需要自己管理加密密钥或在本地存储加密密钥。

如需了解详情，请参阅静态加密和传输加密。

Hadoop Google Cloud 审核

Cloud Audit Logging 可以为每个项目和组织维护多种日志。Google Cloud 服务会将审核日志条目写入这些日志，便于您了解在您的 Google Cloud 项目中“谁在何时何地执行了什么操作”。

如需详细了解审核日志和写入审核日志的服务，请参阅 Cloud Audit Logs 文档。

迁移过程

为了在 Google Cloud 上安全高效地运行 Hadoop 操作，请遵循本部分中介绍的过程进行操作。

在本部分中，我们假设您已设置了 Google Cloud 环境。这包括在 Google Workspace 中创建用户和组。这些用户和组可以手动管理，也可以与 Active Directory 同步，并且您已完成所有配置，以便 Google Cloud 在对用户进行身份验证时能完全正常运行。

确定管理身份的主体

大多数 Google 客户使用 Cloud Identity 来管理身份。但有些客户不使用 Google Cloud 身份管理其公司身份。在这种情况下，他们的 POSIX 和 SSH 权限决定最终用户对云资源的访问权限。

如果您拥有独立的身份系统，请首先创建 Google Cloud 服务账号密钥并下载这些密钥。然后，您可以通过为下载的服务账号密钥文件授予和 POSIX 类似的相应访问权限，将本地 POSIX 和 SSH 安全模型与 Google Cloud 模型桥接。您可以允许或拒绝您的本地身份访问这些密钥文件。

如果您采用此方法，可审核性由您自己的身份管理系统掌握。要提供审核跟踪，您可以使用边缘节点上用户登录的 SSH 日志（其中包含服务账号密钥文件），或者您可以选择偏重量级和显式的密钥库机制从用户获取服务账号凭据。在这种情况下，“服务账号模拟”将在密钥库层写入审核日志。

确定使用单个还是多个数据项目

如果您的组织拥有大量数据，这意味着您需要将数据分开储存到不同的 Cloud Storage 存储桶。您还需要考虑如何将这些数据存储桶分配到各个项目。刚开始使用 Google Cloud 时，您可能只需移动少量数据，随着工作负载和应用的移动，一段时间后需要移动的数据会越来越多。

将所有数据存储桶保留在一个项目下看似方便，但这样做往往不是良策。为了管理数据访问权限，您需要在存储桶中使用带有 IAM 角色的扁平目录结构。随着存储桶数量的增加，管理可能变得更加棘手。

另一种方法是将数据存储在多个项目中，每个项目都专属于不同的组织：一个项目对应财务部门，另一个项目对应法律部门，以此类推。在这种情况下，每个部门都独立管理自己的权限。

数据处理期间，可能需要访问或创建临时存储桶。处理可能需要进行跨信任边界的拆分，例如数据科学家可能需要访问不属于他们的进程生成的数据。

下图显示了单个数据项目下和多个数据项目下 Cloud Storage 中的典型数据结构。

典型的存储选项 - 在单个项目和在多个项目中

在决定哪种方法最适合您的组织时，需要考虑以下要点。

使用单个数据项目：

  • 如果存储桶数量少，管理所有存储桶轻而易举。
  • 权限授予主要由管理员组的成员执行。

使用多个数据项目：

  • 可以更便捷地将管理职责委派给项目所有者。
  • 此方法对于采用不同权限授予过程的组织非常有用。例如，营销部门项目可能与法律部门项目的权限授予流程不同。

确定应用并创建服务账号

如果 Dataproc/Hadoop 集群要与其他 Google Cloud 资源（例如 Cloud Storage）进行交互，您应该确定将在 Dataproc/Hadoop 上运行的所有应用及其需要的访问权限。例如，假设有一个 ETL 作业可以将加利福尼亚州的财务数据填充到 financial-ca 存储桶中。此 ETL 作业需要对上述存储桶进行读写访问。确定使用 Hadoop 的应用后，您可以为各个应用创建服务账号。

请记住，此访问权限不会影响 Dataproc 集群内或 Compute Engine 上的 Hadoop 中的 Linux 用户。

如需详细了解服务账号，请参阅创建和管理服务账号。

授予服务账号权限

当您知道每个应用对不同的 Cloud Storage 存储桶应具有哪些访问权限时，可以在相关的应用服务账号上设置这些权限。如果您的应用还需要访问其他 Google Cloud 组件（例如 BigQuery 或 Bigtable），您还可以通过服务账号授予这些组件权限。

例如，您可以将 operation-ca-etl 指定为 ETL 应用（通过汇总来自加利福尼亚的营销和销售数据来生成运营报告），向其授予将报告写入财务部门数据存储桶的权限。然后，您可以设置 marketing-report-ca 和 sales-report-ca 应用，使其获得对各自部门的读写权限。下图演示了这一设置。

服务账号的权限配置

您应该遵循最小权限原则。该原则要求您只为每个用户或服务账号提供执行一个或多个任务所需的最低权限。Google Cloud 中的默认权限已经过优化，简单易用并可缩短设置时间。要构建较容易通过安全性和合规性审核的 Hadoop 基础架构，您必须设计限制性更高的权限。尽早开始制定并记录这些策略不仅有助于提供安全且合规的流水线，而且还有助于安全和合规团队进行架构审核。

创建集群

计划并配置访问权限后，您可以使用已创建的服务账号创建 Dataproc 集群或 Compute Engine 上的 Hadoop。每种集群都可以根据您为相应服务账号授予的权限访问其他 Google Cloud 组件。确保您为访问 Google Cloud 授予了正确的一个或多个访问权限范围，然后使用服务账号访问权限进行调整。如果出现访问问题，尤其是对于 Compute Engine 上的 Hadoop，请务必检查这些权限。

要使用特定服务账号创建 Dataproc 集群，请使用以下 gcloud 命令：

gcloud dataproc clusters create [CLUSTER_NAME] \
    --service-account=[SERVICE_ACCOUNT_NAME]@[PROJECT+_ID].iam.gserviceaccount.com \
    --scopes=scope[, ...]

由于以下原因，您最好避免使用默认的 Compute Engine 服务账号：

  • 如果多个集群和 Compute Engine 虚拟机使用默认的 Compute Engine 服务账号，则审核非常困难。
  • 默认 Compute Engine 服务账号的项目设置可能不同，这意味着此类账号具有的权限可能多于集群需要的权限。
  • 对默认 Compute Engine 服务账号作出的更改可能会无意中影响甚至破坏您的集群及其中运行的应用。

考虑为每个集群设置 IAM 权限

您可以将多个集群放在一个项目下，以便轻松管理这些集群，但这种方式可能不是确保安全访问的最佳方式。例如，假设项目 A 中存在集群 1 和集群 2，某些用户可能具有操作集群 1 所需的适当权限，但对于集群 2 而言，这些用户具有过多的权限。更糟糕的情况是，这些用户能够访问集群 2，可能仅仅是因为他们处于该项目中，但他们不应该有任何访问权限。

当项目包含许多集群时，对这些集群的访问可能会变得混乱，如下图所示。

访问单个项目中的不同集群

如果您将相似集群分组后放入较小的项目中，然后为每个集群分别配置 IAM，您将能更精确地控制访问权限。现在，用户可以访问适合他们的集群，并且无法访问其他集群。

访问分组到不同项目中的集群

限制对集群的访问

使用服务账号设置访问权限可确保 Dataproc/Hadoop 与其他 Google Cloud 组件之间的安全交互。但是，这么做无法完全控制哪些用户可以访问 Dataproc/Hadoop。例如，集群中具有 Dataproc/Hadoop 集群节点的 IP 地址的用户仍可以使用 SSH 连接到该集群（在某些情况下）或向其提交作业。在本地环境中，系统管理员通常可以使用子网、防火墙规则、Linux 身份验证和其他策略来限制对 Hadoop 集群的访问。

在运行 Dataproc/Compute Engine 上的 Hadoop 时，您可以采用许多方法限制 Google Workspace 或 Google Cloud 身份验证级别的访问。但是，本指南重点介绍 Google Cloud 组件级别的访问。

使用 OS Login 限制 SSH 登录

在本地环境中，如需限制用户连接到 Hadoop 节点，您需要设置边界访问权限控制、Linux 级 SSH 访问和 sudoer 文件。

在 Google Cloud 上，您可以使用以下过程，针对 Compute Engine 实例的连接，配置用户级 SSH 限制：

  1. 在您的项目或单个实例上启用 OS Login 功能。
  2. 向您自己和其他主账号授予必要的 IAM 角色。
  3. 或者，针对您自己和其他主账号向用户账号添加自定义 SSH 密钥。或者，当您连接到实例时，Compute Engine 会自动为您生成这些密钥。

在项目中的一个或多个实例上启用 OS Login 后，这些实例将只接受来自在项目或组织中具有必要 IAM 角色的用户账号的连接。

例如，您可以通过以下过程向您的用户授予实例访问权限：

  1. 将必要的实例访问权限角色授予用户。用户必须具备以下角色：

    • iam.serviceAccountUser 角色

    • 以下某个登录角色：

      • compute.osLogin 角色，该角色不授予管理员权限
      • compute.osAdminLogin 角色，该角色可授予管理员权限

  2. 如果您是组织管理员，并希望允许组织外部的 Google 身份访问您的实例，请在组织级层为这些外部身份授予 compute.osLoginExternalUser 角色。然后，您还必须在项目或组织级层向外部身份授予 compute.osLogin 或 compute.osAdminLogin 角色。

当您配置必要的角色后，请使用 Compute Engine 工具连接到实例。Compute Engine 会自动生成 SSH 密钥并将其与您的用户账号关联。

如需详细了解 OS Login 功能，请参阅使用 OS Login 管理实例访问。

使用防火墙规则限制网络访问

在 Google Cloud 上，您还可以创建使用服务账号来过滤入站或出站流量的防火墙规则。在以下情况下，这种方法尤其有效：

  • 您拥有大量需要访问 Hadoop 的用户或应用，这意味着基于 IP 创建规则非常困难。
  • 您正在运行临时的 Hadoop 集群或客户端虚拟机，因此 IP 地址会经常变化。

将防火墙规则与服务账号搭配使用，您可以设置对特定 Dataproc/Hadoop 集群的访问权限，以仅允许某个服务账号。这样，只有作为该服务账号运行的虚拟机才能在指定级别访问集群。

下图说明了使用服务账号限制访问的过程。dataproc-app-1、dataproc-1、dataproc-2、app-1-client 均为服务账号。防火墙规则允许 dataproc-app-1 访问 dataproc-1 和 dataproc-2，并且允许使用 app-1-client 的客户端访问 dataproc-1。在存储方面，Cloud Storage 访问和权限受服务账号的 Cloud Storage 权限限制，而不受防火墙规则影响。

使用服务账号和防火墙规则限制对资源的访问

对于此类配置，系统已建立以下防火墙规则：

规则名称 设置
dp1 目标：dataproc-1
来源：[IP 地址范围]
来源 SA：dataproc-app-1
允许 [端口]
dp2 目标：dataproc-2
来源：[IP 地址范围]
来源 SA：dataproc-app-2
允许 [端口]
dp2-2 目标：dataproc-2
来源：[IP 地址范围]
来源 SA：dataproc-app-1
允许 [端口]
app-1-client 目标：dataproc-1
来源：[IP 地址范围]
来源 SA：app-1-client
允许 [端口]

如需详细了解如何将防火墙规则与服务账号搭配使用，请参阅按服务账号过滤来源和目标。

检查无意中打开的防火墙端口

对于公开在集群上运行的基于网页的用户界面，创建适当的防火墙规则也很重要。请确保您没有连接到这些接口的网络的开放防火墙端口。开放端口和配置不当的防火墙规则可能允许未经授权的用户执行任意代码。

例如，Apache Hadoop YARN 提供的 REST API 与 YARN 网络界面共享相同的端口。默认情况下，可以访问 YARN 网页界面的用户可以创建应用、提交作业，还可以执行 Cloud Storage 操作。

查看 Dataproc 网络配置和创建 SSH 隧道，以建立与集群控制器的安全连接。如需详细了解如何将防火墙规则与服务账号搭配使用，请参阅按服务账号过滤来源和目标。

多租户集群简介

一般来说，最好针对不同的应用运行单独的 Dataproc/Hadoop 集群。但是，如果您必须使用多租户集群并且不想违反安全要求，则可以在 Dataproc/Hadoop 集群内创建 Linux 用户和组，以便通过 YARN 队列提供授权和资源分配。您必须亲自进行身份验证，因为 Google 用户和 Linux 用户之间不存在直接映射。在集群上启用 Kerberos 可以增强集群范围内的身份验证级别。

有时，自然人用户（例如一组数据科学家）使用 Hadoop 集群来发现数据和构建模型。在此类情况下，最好将共享相同数据访问权限的用户分组并创建一个专用的 Dataproc/Hadoop 集群。这样，您可以将用户添加到有权访问数据的组中。或者，您也可以根据相应的 Linux 用户分配集群资源。