本文档介绍使用 Dataproc 集群上密钥分发中心 (KDC) 和 Apache Ranger 对 Google Cloud 上的 Kerberos 化的数据湖进行联网、身份验证和授权所涉及的概念、最佳做法和参考架构。Dataproc 是 Google Cloud 的托管式 Hadoop 和 Spark 服务。本文档适用于将传统 Hadoop 和 Spark 集群迁移到由 Dataproc 提供支持的现代数据湖的 Apache Hadoop 管理员、云架构师和大数据团队。
Google Cloud 上的 Kerberos 化的数据湖可帮助采用混合云和多云部署的组织扩展和使用其现有的身份和访问权限控制管理投资。
在 Google Cloud 上，组织可以根据需要为团队提供任意数量的作业范围的临时集群。这方法消除了维护具有不断增长的依赖性和软件配置交互的单个集群中存在的大部分复杂性问题。组织还可以创建长时间运行的集群以供多个用户和服务访问。本文档介绍如何使用 Kerberos 和 Apache Ranger 等行业标准工具来帮助确保 Dataproc 上两个集群用例的用户精细安全性（身份验证、授权和审核）。
客户使用场景
企业正将基于本地 Hadoop 的数据湖迁移到公有云平台，以解决管理传统集群时面临的挑战。
其中一个组织是企业软件和硬件领域的大型技术领导者，决定将其本地 Hadoop 系统迁移到 Google Cloud。其本地 Hadoop 环境满足了数百个团队和业务部门的分析需求，包括拥有 200 个数据分析团队成员的信息安全团队。当一个团队成员使用旧版数据湖运行大型查询时，由于其资源的刚性性质遇到了问题。该组织很难借助其本地环境满足团队的分析需求，因此迁移到 Google Cloud。通过迁移到 Google Cloud，该组织能够每月将本地数据湖上报告的问题数减少 25%。
该组织针对 Google Cloud 的迁移计划的基础是决定根据团队的工作负载重塑和优化其大型单体式集群，并将重点从集群管理转移到挖掘业务价值。少数大型集群拆分为较小的经济实惠的 Dataproc 集群，而工作负载和团队迁移到以下类型的模型：
- 临时作业范围的集群：启动时间只有几分钟，临时模型允许作业或工作流具有一个专用集群，该集群会在作业完成时关停。此模式通过将 Hadoop 分布式文件系统 (HDFS) 替换为 Cloud Storage 并使用 Dataproc 的内置适用于 Hadoop 的 Cloud Storage 连接器，将存储与计算节点分离开来。
- 半长时间运行的集群：如果临时作业范围的集群无法处理用例，则 Dataproc 集群可以长时间运行。当集群的有状态数据分流到 Cloud Storage 时，集群可以轻松关停，并被视为半长时间运行。智能集群自动扩缩功能还允许这些集群从小规模起步并针对特定应用优化计算资源。此自动扩缩取代了 YARN 队列的管理。
混合安全挑战
在前面的客户场景中，客户将其大量数据管理系统迁移到了云。但是，组织的 IT 的其他部分需要保留在本地（例如，为数据湖提供数据的一些旧版操作系统）。
帮助确保基于 LDAP 的本地中央身份提供商 (IdP) 的安全架构仍然是其使用数据湖的企业身份的权威来源。本地 Hadoop 安全性基于 Kerberos 和 LDAP 进行身份验证（通常作为组织的 Microsoft Active Directory (AD) 的一部分）以及其他几个开源软件 (OSS) 产品，例如 Apache Ranger。此安全方法允许对数据湖集群中的用户活动和团队活动进行细粒度授权和审核。在 Google Cloud 上，Identity and Access Management (IAM) 用于管理对特定 Google Cloud 资源（例如 Dataproc 和 Cloud Storage）的访问权限。
本文档介绍了充分利用本地和 OSS Hadoop 安全（侧重于 Kerberos、公司 LDAP 和 Apache Ranger）以及 IAM 以帮助保护 Hadoop 集群内部和外部的工作负载和数据的安全方法。
架构
下图展示了高级别的基础架构：
在上图中，客户端在多团队或单团队集群上运行作业。集群使用采用公司身份提供商的中央 Hive Metastore 和 Kerberos 身份验证。
组件
该架构建议了一个业界标准开源工具和 IAM 组合，用于对本文档后面部分介绍的不同作业提交方式进行身份验证和授权。以下是主要组件，这些组件协同工作，可以在 Hadoop 集群中为团队和用户工作负载提供精细的安全：
Kerberos：Kerberos 是一种网络身份验证协议，该协议使用 Secret 密钥加密为客户端/服务器应用提供强身份验证。Kerberos 服务器称为密钥分发中心 (KDC)。
Kerberos 广泛用于 AD 等本地系统，以便对真人用户、服务和机器进行身份验证（客户端实体表示为“用户主账号”）。在 Dataproc 上启用 Kerberos 使用免费的 MIT Kerberos 分发创建集群上 KDC。Dataproc 的集群上 KDC 会响应用户主账号访问集群内的资源（例如 Apache Hadoop YARN、HDFS 和 Apache Spark）的请求（服务器资源表示为“服务器主账号”）。Kerberos 跨域信任允许您将一个域的用户主账号连接到另一个域。
Apache Ranger：Apache Ranger 为用户提供了精细的授权，可以对 Hadoop 服务执行特定操作。它还会审核用户访问权限并执行管理操作。Ranger 可以与本地公司 LDAP 服务器或 AD 同步，以获取用户和服务身份。
共享 Hive Metastore：Hive Metastore 是一项用于存储 Apache Hive 和其他 Hadoop 工具的元数据的服务。由于许多工具都是围绕其构建的，因此 Hive Metastore 已成为许多数据湖的关键组件。在所提议的架构中，集中式和 Kerberos 化的 Hive Metastore 允许多个集群以安全的方式共享元数据。
虽然 Kerberos、Ranger 和共享 Hive Metastore 可以协同工作，从而在 Hadoop 集群中实现精细的用户安全，但 IAM 可控制对 Google Cloud 资源的访问权限。例如，Dataproc 使用 Dataproc 服务账号对 Cloud Storage 存储桶执行读写操作。
集群维度
以下维度描述了 Dataproc 集群的特征：
- 租户：如果集群响应多个真人用户或服务的请求，则集群为多租户；如果集群响应单个用户或服务的请求，则集群为单租户。
- Kerberos：如果在 Dataproc 上启用 Kerberos，则集群可以为 Kerberos 化的集群；如果未在 Dataproc 上启用 Kerberos，则集群可以为非 Kerberos 化的集群。
- 生命周期：如果集群仅在特定作业或工作流期间创建，仅包含运行作业所需的资源，并在作业完成时关停，则集群为临时集群。否则，集群被视为半长时间运行的集群。
这些维度的不同组合决定了特定集群最适合的用例。本文档讨论了以下代表性示例：
架构中显示的多团队集群示例是 Kerberos 化、多租户、半长时间运行的集群。这些集群最适合交互式查询工作负载，例如，提供长期数据分析和商业智能 (BI) 探索。在此架构中，集群位于 Google Cloud 项目中，该项目由多个团队共享并处理这些团队的请求，因此得名。
在本文档中，“团队”或“应用团队”一词用于描述组织中使用同一软件组件或作为一个职能团队的一组人员。例如，团队可能指代微服务的后端开发者、业务应用的 BI 分析师，甚至是跨职能团队（例如大数据基础架构团队）。
架构中显示的单团队集群示例是可以为多租户（属于同一团队的成员）或单租户的集群。
- 作为临时集群，单团队集群可以用于作业，例如，数据工程师运行 Spark 批处理作业，数据科学家运行模型训练作业。
作为半长时间运行的集群，单团队集群可以处理范围限定为单个团队或单个人的数据分析和 BI 工作负载。
单团队集群位于属于一个团队的 Google Cloud 项目中，这有助于简化使用情况审核、结算和资源隔离。例如，只有单个团队的成员才能访问用于保存集群数据的 Cloud Storage 存储分区。在此方法中，应用团队拥有专用项目，因此单一团队集群不会进行 Kerberos 化。
我们建议您分析特定要求，并选择最适合您的情况的维度组合。
提交作业
用户可以使用各种工具将作业提交到两种类型的集群，这些工具包括：
- 使用 REST 调用或客户端库的 Dataproc API。
- Google Cloud CLI gcloud 命令行工具中的本地终端窗口，或者 Google Cloud Console 中的 Cloud Shell（在本地浏览器中打开）。
- Dataproc 工作流模板，它是一个可重复使用的工作流配置，用于定义作业图，其中包含在哪里运行这些作业的信息。如果工作流使用代管式集群选项，则它会使用临时集群。
- Cloud Composer（使用 Dataproc 运算符）。Composer 有向无环图 (DAG) 也可用于编排 Dataproc 工作流模板。
- 在集群中打开 SSH 会话连接到主节点，并直接提交作业，或者使用 Apache Beeline 等工具。该工具通常仅为管理员和高级用户预留。例如，高级用户是开发者，他们希望排查服务配置参数的问题，并通过直接在主节点上运行测试作业来验证这些参数。
网络
下图突出显示了架构的网络概念：
在上图中，网络架构使用网状混合模式，其中一些资源位于 Google Cloud 上，一些资源位于本地。网状混合模式使用共享 VPC，其中包含一个共同的宿主项目以及每个 Dataproc 集群类型和团队的独立项目。下文的 Google Cloud 和本地部分详细介绍了此架构。
在 Google Cloud 上
在 Google Cloud 上，该架构使用共享 VPC 进行构建。共享 VPC 允许将多个项目中的资源连接到一个公用 VPC 网络。通过使用公用 VPC 网络，资源可以使用该网络的内部 IP 地址安全高效地相互通信。如需设置共享 VPC，请创建以下项目：
- 宿主项目：宿主项目包含一个或多个服务项目使用的共享 VPC 网络。
服务项目：服务项目包含相关的 Google Cloud 资源。Shared VPC Admin 可以将服务项目附加到宿主项目，以便使用共享 VPC 网络中的子网和资源。此连接对于单团队集群能够访问集中的 Hive Metastore 至关重要。
如网络图所示，我们建议为 Hive Metastore 集群、多团队集群和每个团队的集群创建单独的服务项目。然后，组织中每个团队的成员可以在其各自的项目中创建单团队集群。
如需允许混合网络中的组件进行通信，您必须配置防火墙规则以允许以下流量：
- Hadoop 服务的内部集群流量，包括 HDFS NameNode 与 HDFS DataNode 通信，以及 YARN ResourceManager 与 YARN NodeManager 通信。我们建议针对这些规则使用使用集群服务账号过滤。
- 特定端口上用于与 Hive Metastore（端口
tcp:9083,8020）、本地 KDC（端口tcp:88）和 LDAP（端口636）以及特定场景中使用的其他集中式外部服务（例如 Google Kubernetes Engine (GKE) 上的 Kafka）通信的外部集群流量。
此架构中的所有 Dataproc 集群仅使用内部 IP 地址创建。如需允许集群节点访问 Google API 和服务，您必须为集群子网启用专用 Google 访问通道。如需允许管理员和高级用户访问专用 IP 地址虚拟机实例，请使用 IAP TCP 转发通过加密隧道转发 SSH、RDP 和其他流量。
通过 Dataproc 组件网关可以安全地访问集群应用程序和可选组件（例如 Spark、Hadoop、Jupyter 和 Zeppelin）的集群 Web 界面。Dataproc 组件网关是一个 HTTP - 基于 Apache Knox 的反向代理。
本地
本文档假定位于本地的资源是公司 LDAP 目录服务以及在其中定义用户和团队服务主账号的公司 Kerberos 密钥分发中心 (KDC)。如果您不需要使用本地身份提供商，则可以使用 Cloud Identity 和 Dataproc 集群或虚拟机上的 KDC 简化设置。
如需与本地 LDAP 和 KDC 通信，您可以使用 Cloud Interconnect 或 Cloud VPN。此设置有助于确保在 RFC 1918 IP 地址中的子网不重叠的情况下，环境之间的通信使用专用 IP 地址。如需详细了解不同的连接方案，请参阅选择网络连接产品。
在混合场景中，身份验证请求必须以最低延时处理。如需实现此目标，您可以使用以下方法：
- 处理集群上 KDC 上的服务身份的所有身份验证请求，并且仅使用集群外部的身份提供商为用户身份。大多数身份验证流量应该是来自服务身份的请求。
- 如果您使用 AD 作为身份提供商，用户正文名称 (UPN) 表示真人用户和 AD 服务账号。我们建议您将 UPN 从本地 AD 复制到靠近数据湖集群的 Google Cloud 区域。此 AD 副本处理 UPN 的身份验证请求，因此请求永远不会传输到本地 AD。每个集群上的 KDC 使用第一种方法处理服务正文名称 (SPN)。
下图显示了同时使用这两种技术的架构：
在上图中，本地 AD 将 UPN 同步到 Google Cloud 区域中的 AD 副本。AD 副本对 UPN 进行身份验证，集群上的 KDC 对 SPN 进行身份验证。
如需了解如何在 Google Cloud 上部署 AD，请参阅部署容错 Microsoft Active Directory 环境。如需了解如何调整网域控制器的实例数量，请参阅集成 MIT Kerberos 和 Active Directory。
身份验证
下图显示了用于对不同 Hadoop 集群中的用户进行身份验证的组件。身份验证允许用户使用 Apache Hive 或 Apache Spark 等服务。
在上图中，Kerberos 域中的集群可以设置跨域信任，以使用其他集群（例如 Hive Metastore）上的服务。非 Kerberos 化的集群可以通过 Kerberos 客户端和账号 Keytab 来使用其他集群上的服务。
共享且安全的 Hive Metastore
集中式 Hive Metastore 允许运行不同开源查询引擎（例如 Apache Spark、Apache Hive/Beeline 和 Presto）的多个集群共享元数据。
您可以在 Kerberized Dataproc 集群上部署 Hive Metastore 服务器，并在远程 RDBMS（例如 Cloud SQL 上的 MySQL 实例）上部署 Hive Metastore 数据库。作为共享服务，Hive Metastore 集群仅处理经过身份验证的请求。如需详细了解如何配置 Hive Metastore，请参阅在 Dataproc 上使用 Apache Hive。
除了 Hive Metastore，您还可以使用 Dataproc Metastore，它是全代管式高可用性（在区域内）的无服务器 Apache Hive Metastore，具有自动修复功能。您还可以按照为服务配置 Kerberos 中所述为 Dataproc Metastore 服务启用 Kerberos。
Kerberos
在此架构中，多团队集群用于分析目的，并且按照 Dataproc 安全配置指南进行 Kerberos 化。Dataproc 安全模式会创建集群上 KDC，并按照 Hadoop 安全模式规范的要求管理集群的服务主账号和 Keytab。
Keytab 是一个文件，其中包含一对或多对 Kerberos 主账号，以及该主账号密钥的加密副本。在无法使用 kinit 命令进行交互式登录时，Keytab 允许以编程方式进行 Kerberos 身份验证。
访问 Keytab 意味着能够模拟其中包含的主账号。因此，keytab 是一个高度敏感的文件，需要安全传输和存储。我们建议您先使用 Secret Manager 存储 keytab 的内容，然后再传输到各自的集群。如需查看有关如何存储 keytab 的内容的示例，请参阅为服务配置 Kerberos。在 keytab 下载到集群主节点后，该文件必须具有受限的文件访问权限。
集群上的 KDC 会处理该集群中所有服务的身份验证请求。大多数身份验证请求都应该是此类请求。为了最大限度地减少延迟时间，KDC 必须在不离开集群的情况下解析这些请求。
其余请求来自真人用户和 AD 服务账号。Google Cloud 上的 AD 副本或本地中央 ID 提供程序会处理这些请求，如前面的本地部分所述。
在此架构中，单团队集群没有 Kerberos 化，因此不存在 KDC。如需允许这些集群访问共享 Hive Metastore，您只需安装 Kerberos 客户端。如需自动执行访问，您可以使用团队的 keytab。如需了解详情，请参阅本文档后面的身份映射部分。
多团队集群中的 Kerberos 跨域信任
如果您的工作负载是混合或多云工作负载，则跨域信任高度相关。借助跨域信任，您可以将中央公司身份集成到 Google Cloud 数据湖中提供的共享服务。
在 Kerberos 中，域在通用 KDC 下定义了一组系统。通过跨域身份验证，来自一个域的用户主账号可以在另一个域中进行身份验证并使用其服务。此配置要求您在域之间建立信任。
在此架构中有三个域：
- EXAMPLE.COM：公司域，其中定义了用户、团队和服务 (UPN) 的所有 Kerberos 用户主账号。
- MULTI.EXAMPLE.COM：是包含多团队集群的域。该集群预先配置了 Hadoop 服务（例如 Apache Spark 和 Apache Hive）的服务主账号 (SPN)。
- METASTORE.EXAMPLE.COM：是 Hive Metastore 域。
单团队集群不进行 Kerberos 化，因此不属于域。
为了能够在所有集群中使用公司用户主账号，您需要建立以下单向跨域信任：
将多团队域和 Metastore 域配置为信任公司域。通过此配置，在公司域中定义的主账号可以访问多团队集群和 Metastore。
虽然信任可能具有传递性，但我们建议您将 Metastore 域配置为直接信任公司域。此配置可避免依赖于多团队域的可用性。
将 Metastore 域配置为信任多团队域，以便多团队集群可以访问 Metastore。这是允许 HiveServer2 主账号访问 Metastore 所必需的配置。
如需了解详情，请参阅 GitHub 代码库中开始使用具有跨域信任的 Kerberse 化的 Dataproc 集群及其相应的 Terraform 配置文件。
如果您更喜欢内置或云原生 IAM 方法来处理多团队集群，并且不需要混合身份管理，请考虑使用基于 Dataproc 服务账号的安全多租户。在这些集群中，多个 IAM 身份能够以不同的服务账号身份访问 Cloud Storage 和其他 Google 资源。
单团队集群中的身份映射
前面几个部分介绍了架构的 Kerberos 化方面的配置。但是，单团队集群不进行 Kerberos 化，因此需要采用一种特殊的方法才能参与此生态系统。此方法使用 Google Cloud 项目隔离属性和 IAM 服务账号来隔离并帮助保护应用团队的 Hadoop 工作负载。
如前面的网络部分所述，每个团队都有一个对应的 Google Cloud 项目，可以在其中创建单团队集群。在单团队集群中，团队的一个或多个成员是集群的租户。按项目隔离的方法还限制了各个团队对 Cloud Storage 存储桶（由这些集群使用）的访问权限。
管理员创建服务项目并在该项目中预配团队服务账号。创建集群时，此服务账号会被指定为集群服务账号。
管理员还为公司域中的团队创建 Kerberos 主账号，并创建其相应的 Keytab。Keytab 安全地存储在 Secret Manager 中，管理员会将 Keytab 复制到集群主节点中。Kerberos 主账号允许从单团队集群访问 Hive Metastore。
为便于自动预配和轻松识别这些相关身份对，身份应遵循通用的命名惯例，例如：
- 团队服务账号：
revenue-reporting-app@proj-A.iam.gserviceaccount.com - Kerberos 团队主账号：
revenue_reporting/app@EXAMPLE.COM
这种身份映射方法提供了一种独特的将 Kerberos 身份映射到服务账号（两者都属于同一团队）的方式。
这些身份的使用方式不同：
- Kerberos 身份可为集群授予共享 Hadoop 资源（例如 Hive Metastore）的访问权限。
- 服务账号可让集群访问共享 Google Cloud 资源，例如 Cloud Storage。
此方法可避免为团队的每个成员创建类似的映射。但是，由于此方法为整个团队使用一个服务账号或一个 Kerberos 主账号，因此系统无法跟踪 Hadoop 集群中的操作。
如需管理对团队项目中 Hadoop 集群范围以外的云资源（例如 Cloud Storage 存储桶、代管式服务和虚拟机）的访问权限，管理员需要将团队成员添加到 Google 群组。管理员可以使用 Google 群组来管理 IAM 权限，以便整个团队可以访问云资源。
如果将 IAM 权限授予群组而非群组的个别成员，则在成员加入或退出应用团队时可以简化用户访问权限的管理。通过向团队的 Google 群组授予直接 IAM 权限，您可以停用服务账号模拟，这有助于简化 Cloud Audit Logs 中操作的可追溯性。定义团队成员时，我们建议您平衡访问权限管理、资源使用和审核所需的细化程度，具体根据这些任务产生的管理工作。
如果集群严格地为一个自然人用户（单租户集群）而不是团队提供服务，请考虑使用 Dataproc 个人集群身份验证。启用了个人集群身份验证的集群仅适用于短期交互式工作负载，可以作为一个最终用户身份安全地运行。这些集群使用 IAM 最终用户凭据与其他 Google Cloud 资源（例如 Cloud Storage）进行交互。集群以最终用户身份进行身份验证，而不是以集群服务账号进行身份验证。在此类集群中，Kerberos 会自动启用并配置为在个人集群中进行安全通信。
身份验证流程
如需在 Dataproc 集群上运行作业，用户可以选择多个选项，如前面提交作业部分中所述。在所有情况下，用户的用户账号或服务账号必须有权访问集群。
当用户在多团队集群上运行作业时，有两个选项可用于 Kerberos 主体，如下图所示：
上图显示了以下选项：
- 如果用户使用 Google Cloud 工具（例如 Dataproc API、Cloud Composer 或 gcloud 命令行工具）提交作业请求，则集群将使用 Dataproc Kerberos 主账号通过 KDC 进行身份验证并访问 Hive Metastore。
- 如果用户通过 SSH 会话运行作业，则可以使用自己的用户 Kerberos 主账号直接在该会话中提交作业。
当用户在单团队集群上运行作业时，可能只有一个 Kerberos 主账号（团队 Kerberos 主账号），如下图所示：
在上图中，当作业需要访问共享 Hive Metastore 时，作业使用团队 Kerberos 主账号。否则，由于单团队集群为非 Kerberos 化集群，因此用户可以使用自己的用户账号启动作业。
对于单团队集群，最好在创建集群时执行初始化操作的过程中为团队主账号运行 kinit。创建集群后，请使用有效期 (-l) 命令选项，根据定义的票据有效期使用 cron 时间表。如需运行 kinit，初始化操作首先将 Keytab 下载到集群主节点。
出于安全考虑，您必须限制对 keytab 的访问。仅将 POSIX 读取权限授予运行 kinit 的账号。如果可能，请删除密钥表并使用 kinit -R 更新令牌以使用 cron 作业延长其生命周期，直到达到最长票证生命周期。届时，cron 作业可以重新下载 keytab、重新运行 kinit 并重启续订周期。
多团队和单团队集群类型均使用服务账号访问其他 Google Cloud 资源，例如 Cloud Storage。单团队集群使用团队服务账号作为自定义集群的服务账号。
授权
本部分介绍了每个集群的粗粒度和细粒度授权机制，如下图所示：
上图中的架构使用 IAM 进行粗粒度授权，使用 Apache Ranger 进行细粒度授权。以下各部分介绍了这些授权方法：粗粒度授权和细粒度授权。
粗粒度授权
借助 IAM，您可以控制用户和群组对项目资源的访问权限。IAM 可定义权限以及授予这些权限的角色。
预定义的 Dataproc 角色有四种：admin、Editor、Viewer 和 Worker。这些角色会授予 Dataproc 权限，让用户和服务账号对集群、作业、操作和工作流模板执行特定操作。这些角色会授予对完成任务所需的 Google Cloud 资源的访问权限。其中一个资源是 Cloud Storage，我们建议使用它作为集群存储层，而不是 HDFS。
IAM Dataproc 权限的粒度不会扩展到在每个集群（例如 Apache Hive 或 Apache Spark）上运行的服务级别。例如，您可以授权特定账号访问 Cloud Storage 存储桶中的数据或运行作业。但是，您无法指定允许该账号通过作业访问哪些 Hive 列。下一部分介绍如何在集群中实现此类细粒度授权。
细粒度授权
如需授权精细访问，您可以使用在 Dataproc 上使用 Apache Ranger 的最佳做法中描述的架构中的 Dataproc Ranger 可选组件。在该架构中，Apache Ranger 安装在每个集群中（无论是单个团队还是多团队）。Apache Ranger 可以在服务、表或列级层为 Hadoop 应用提供精细的访问权限控制（授权和审核）。
Apache Ranger 使用由公司 LDAP 代码库提供并定义为 Kerberos 主账号的身份。在多团队集群中，Ranger UserSync 守护程序会定期更新公司 LDAP 服务器中的 Kerberos 化的身份。在单团队集群中，只需要团队身份。
临时集群带来一项挑战，因为这些集群在作业完成后会关停，但不得丢失其 Ranger 政策和管理员日志。为应对此挑战，您需要将政策外部化到中央 Cloud SQL 数据库，并将审核日志外部化到 Cloud Storage 文件夹。如需了解详情，请参阅在 Dataproc 上使用 Apache Ranger 的最佳做法。
授权流程
当用户要访问一项或多项集群服务以处理数据时，请求会经过以下流程：
- 用户通过身份验证流程部分中所述的选项之一进行身份验证。
- 目标服务接收用户请求并调用相应的 Apache Ranger 插件。
- 该插件定期从 Ranger 政策服务器检索政策。这些政策决定了是否允许用户身份对特定服务执行请求的操作。如果允许用户身份执行操作，则该插件让服务可以处理请求，并且用户会获取结果。
- Ranger 审核服务器会将每次与 Hadoop 服务交互（无论是允许还是拒绝）写入 Ranger 日志。每个集群在 Cloud Storage 中都有自己的日志文件夹。Dataproc 还会写入作业和集群日志，您可以在 Cloud Logging 中查看、搜索、过滤和归档这些日志。
在本文档中，参考架构使用两种类型的 Dataproc 集群：多团队集群和单团队集群。通过使用易于预配和保护的多个 Dataproc 集群，组织可以使用作业、产品或以网域为中心的方法，而不是传统的集中式集群。此方法可与整体数据网格架构完美配合，该架构允许团队完全拥有并保护其数据湖及其工作负载，并提供数据即服务。
后续步骤
- 了解 GitHub 代码库中开始使用具有跨域信任的 Kerberse 化的 Dataproc 集群及其相应的 Terraform 配置文件。
- 了解在 Dataproc 上使用 Apache Ranger 的最佳做法。
- 了解如何使用 Tableau 和 Looker 等商业智能 (BI) 工具在 Dataproc 上为数据分析师设置安全数据访问权限。
- 了解如何将本地 Apache Hadoop 系统迁移到 Google Cloud。
- 了解联合 Google Cloud 与外部身份提供商的最佳做法。
- 如需查看更多参考架构、图表和最佳实践，请浏览云架构中心。