Kerberos 架构选项 - Amazon EMR

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

Kerberos 架构选项

当您将 Kerberos 与 Amazon 配合使用时EMR,您可以从本节列出的架构中进行选择。不论选择什么架构,您都使用相同步骤来配置 Kerberos。您可以创建安全配置,在创建集群时指定安全配置和兼容的特定于集群的 Kerberos 选项,并为集群上的 Linux 用户创建与中的用户主体相匹配的HDFS目录。KDC有关各个架构的配置选项及示例配置的说明,请参阅在亚马逊上配置 Kerberos EMR

集群专用KDC(KDC在主节点上)

此配置适用于亚马逊 5.10.0 及更高EMR版本。

Amazon EMR集群 architecture with master node, core nodes, and task node within a Kerberos realm.
优点
  • 亚马逊EMR拥有该产品的全部所有权KDC。

  • EMR集群KDC上的独立于集中式KDC实现,例如 Microsoft Active Directory 或 AWS Managed Microsoft AD。

  • 对性能的影响微乎其微,因为仅KDC管理集群中本地节点的身份验证。

  • 或者,其他 Kerberized 集群可以将KDC作为外部集群引用。KDC有关更多信息,请参阅 外部 KDC-不同群集上的主节点

注意事项和限制
  • 使用 Kerberos 的集群无法彼此进行身份验证,因此应用程序无法互操作。如果集群应用程序需要互操作,则必须在集群之间建立跨领域信任,或者将一个集群设置KDC为其他集群的外部集群。如果建立了跨领域信任,则KDCs必须具有不同的 Kerberos 领域。

  • 您必须在主节点的EC2实例上创建与用户主体相对应的 Linux KDC 用户以及每个用户的HDFS目录。

  • 用户委托人必须使用EC2私钥文件和kinit凭据才能使用SSH连接到集群。

跨领域信任

在此配置中,来自不同 Kerberos 领域的委托人(通常是用户)向 Kerberized 集群上的应用程序组件进行身份验证,该群集有自己的EMR集群。KDC主节点KDC上的,KDC使用两个节点中都KDCs存在的跨领域主体与另一个节点建立信任关系。每个主体名称和密码都精确匹配KDC。跨领域信任在 Active Directory 实现中最常见,如下图所示。还支持与外部集群MITKDC或其他 Amazon EMR 集群KDC上的跨领域信任。

Amazon EMR clusters in different Kerberos realms with cross-realm trust to Active Directory.
优点
  • 安装的EMR集群保留KDC对的完全所有权KDC。

  • 借助 Active Directory,亚马逊EMR会自动创建与中的用户主体相对应的 Linux 用户。KDC您仍然必须为每个用户创建HDFS目录。此外,Active Directory 域中的用户委托人可以使用kinit凭据访问 Kerberized 集群,无需EC2私钥文件。这消除了在集群用户之间共享私有密钥文件的需求。

  • 由于每个集群都KDC管理集群中节点的身份验证,因此可以最大限度地减少集群中大量节点的网络延迟和处理开销的影响。

注意事项和限制
  • 如果您使用 Active Directory 领域建立信任,则必须提供 Active Directory 用户名和密码,在您在创建集群时,该用户应有权将委托人加入域。

  • 无法在具有相同名称的 Kerberos 领域之间建立跨领域信任。

  • 跨领域信任必须明确建立。例如,如果集群 A 和集群 B 都与 a 建立了跨领域信任KDC,则它们本质上不会相互信任,并且它们的应用程序也无法相互进行身份验证以实现互操作。

  • KDCs必须独立维护和协调,以便用户主体的凭据精确匹配。

外部 KDC

Amazon EMR 5.20.0 及更高版本支持使用外部KDC配置。

外部 KDC — MIT KDC

此配置允许一个或多个EMR群集使用MITKDC服务器中定义和维护的主体。

Amazon EMR集群 architecture with Kerberos realm, showing master, core, and task nodes.
优点
  • 管理委托人合并为一个KDC。

  • 多个集群可以在同一 Kerberos KDC 领域中使用相同的集群。有关更多信息,请参阅 使用具有相同功能的多个集群的要求 KDC

  • Kerberized 群集上的主节点不承担与维护相关的性能负担。KDC

注意事项和限制
  • 您必须在每个 Kerberized 集群的主节点的EC2实例上创建与KDC用户主体相对应的 Linux 用户,以及每个用户的HDFS目录。

  • 用户委托人必须使用EC2私钥文件和kinit凭据才能使用连接到 Kerberized 集群。SSH

  • Kerberized EMR 集群中的每个节点都必须有通往的网络路由。KDC

  • Kerberized 集群中的每个节点都会给外部节点带来身份验证负担KDC,因此配置KDC会影响集群性能。配置KDC服务器硬件时,请考虑同时支持的最大 Amazon EMR 节点数。

  • 集群性能取决于 Kerberized 集群中节点与之间的网络延迟。KDC

  • 由于相互依赖关系,问题排查可能会更加困难。

外部 KDC-不同群集上的主节点

此配置与上述外部MITKDC实现几乎相同,唯一的不同KDC是位于EMR群集的主节点上。有关更多信息,请参阅集群专用KDC(KDC在主节点上)教程:配置与 Active Directory 域的跨领域信任

Diagram of Amazon EMR clusters with Kerberos realm, showing master and core nodes.
优点
注意事项和限制
  • 您必须在每个 Kerberized 集群的主节点的EC2实例上创建与KDC用户主体相对应的 Linux 用户,以及每个用户的HDFS目录。

  • 用户委托人必须使用EC2私钥文件和kinit凭据才能使用连接到 Kerberized 集群。SSH

  • 每个EMR集群中的每个节点都必须有通往的网络路由KDC。

  • Kerberized 集群中的每个 Amazon EMR 节点都会给外部节点带来身份验证负担KDC,因此配置KDC会影响集群性能。配置KDC服务器硬件时,请考虑同时支持的最大 Amazon EMR 节点数。

  • 集群性能取决于集群中节点与之间的网络延迟KDC。

  • 由于相互依赖关系,问题排查可能会更加困难。

外部 KDC-在另一个集群KDC上使用 Active Directory 跨领域信任的群集

在此配置中,您首先创建一个集群专用集群,该集群与 Activ KDC e Directory 具有单向跨领域信任。有关详细教程,请参阅 教程:配置与 Active Directory 域的跨领域信任。然后,您启动其他集群,将具有信任KDC的集群引用为外部KDC集群。有关示例,请参阅KDC具有活动目录跨领域信任的外部集群。这允许使用外部KDC的每个亚马逊EMR集群对在 Microsoft Active Directory 域中定义和维护的委托人进行身份验证。

Amazon EMR clusters with Kerberos authentication and Active Directory integration diagram.
优点
  • 在 Active Directory 域中,委托人的管理进行了整合。

  • 亚马逊EMR加入了 Active Directory 领域,这样就无需创建与 Active Directory 用户相对应的 Linux 用户。您仍然必须为每个用户创建HDFS目录。

  • 多个集群可以在同一 Kerberos KDC 领域中使用相同的集群。有关更多信息,请参阅 使用具有相同功能的多个集群的要求 KDC

  • Active Directory 域中的用户委托人可以使用kinit凭据访问 Kerberized 集群,无需EC2私钥文件。这消除了在集群用户之间共享私有密钥文件的需求。

  • 只有一个 Amazon EMR 主节点负责维护KDC,而且只有该集群必须使用 Active Directory 凭证创建,才能实现与 Active Directory 之间的跨领域信任。KDC

注意事项和限制
  • 每个EMR群集中的每个节点都必须有通往KDC和 Active Directory 域控制器的网络路由。

  • 每个 Amazon EMR 节点都会给外部节点带来身份验证负担KDC,因此配置会KDC影响集群性能。配置KDC服务器硬件时,请考虑同时支持的最大 Amazon EMR 节点数。

  • 集群性能取决于群集中的节点和KDC服务器之间的网络延迟。

  • 由于相互依赖关系,问题排查可能会更加困难。

使用具有相同功能的多个集群的要求 KDC

多个集群可以在同一 Kerberos KDC 领域中使用相同的集群。但是,如果集群同时运行,则如果集群使用的 Kerberos ServicePrincipal 名称存在冲突,则集群可能会失败。

如果您有多个具有相同外部集群的并发集群KDC,请确保这些集群使用不同的 Kerberos 领域。如果集群必须使用相同的 Kerberos 领域,请确保集群位于不同的子网中,并且它们的CIDR范围不重叠。