Cloudera安全认证概述

Cloudera安全认证概述
+ 查看更多

1.Cloudera Manager身份认证概述

身份验证是任何计算环境的基本安全要求。简单来说，用户和服务必须先向系统证明其身份（身份验证），然后才能在授权范围内使用系统功能。身份验证和授权携手并进，以保护系统资源。授权使用多种方式处理，从访问控制列表（ACL）到HDFS扩展ACL，再到使用Ranger的基于角色的访问控制（RBAC）。

几种不同的机制一起工作以对集群中的用户和服务进行身份验证。这些取决于集群上配置的服务。大多数CDH组件，包括Apache Hive，Hue和Apache Impala，都可以使用Kerberos进行身份验证。可以将MIT和Microsoft Active Directory Kerberos实现集成在一起，以与Cloudera集群一起使用。

另外，可以在LDAP兼容的身份服务（例如Windows Server的核心组件OpenLDAP和Microsoft Active Directory）中存储和管理Kerberos凭据。

本节提供简要概述，并特别关注使用Microsoft Active Directory进行Kerberos身份验证或将MIT Kerberos和Microsoft Active Directory集成时可用的不同部署模型。

Cloudera不提供Kerberos实现。可以将Cloudera集群配置为使用Kerberos进行身份验证，即MIT Kerberos或Microsoft Server Active Directory Kerberos，特别是密钥分发中心或KDC。必须先设置Kerberos实例并使其运行，然后才能配置集群以使用它。

收集有关KDC的所有配置详细信息（或在设置过程中让Kerberos管理员可以帮助您）是与集群和Kerberos集成无关的一项重要的初步任务，而与部署模型无关。

2.Kerberos概述

简而言之，Kerberos是一种身份验证协议，它依赖于加密机制来处理发出请求的客户端与服务器之间的交互，从而极大地降低了模拟的风险。密码既不存储在本地也不通过网络明文发送。用户在登录其系统时输入的密码用于解锁本地机制，然后在与受信任的第三方的后续交互中使用该机制来向用户授予票证（有效期有限），该票证用于根据请求进行身份验证服务。在客户端和服务器进程相互证明各自的身份之后，对通信进行加密以确保隐私和数据完整性。

受信任的第三方是Kerberos密钥分发中心（KDC），它是Kerberos操作的焦点，它也为系统提供身份验证服务和票证授予服务（TGS）。简要地说，TGS向请求的用户或服务发行票证，然后将票证提供给请求的服务，以证明用户（或服务）在票证有效期内的身份（默认为10小时）。Kerberos有许多细微差别，包括定义用于标识系统用户和服务的主体，票证续订，委托令牌处理等。请参见Kerberos安全工件概述。

此外，这些过程大部分完全透明地发生。例如，集群的业务用户只需在登录时输入密码，票证处理，加密和其他详细信息就会在后台自动进行。此外，由于使用了票证和Kerberos基础结构中的其他机制，用户不仅通过了单个服务目标，还通过了整个网络的身份验证。

3.Kerberos部署模型

可以在符合LDAP的身份/目录服务（例如OpenLDAP或Microsoft Active Directory）中存储和管理Kerberos身份验证所需的凭据。

一次，Microsoft提供了一种独立的服务，即Active Directory服务现在打包为Microsoft Server Domain Services的一部分。在2000年代初期，Microsoft用Kerberos取代了其NT LAN Manager身份验证机制。这意味着运行Microsoft Server的站点可以将其集群与Active Directory for Kerberos集成在一起，并将凭据存储在同一服务器的LDAP目录中。

本节概述了可用于将Kerberos身份验证与Cloudera集群集成的不同部署模型，以及可用方法的一些优点和缺点。

本地MIT KDC

此方法使用集群本地的MIT KDC。用户和服务可以与本地KDC进行身份验证，然后才能与集群上的CDH组件进行交互。

架构摘要：

MIT KDC和单独的Kerberos领域本地部署到CDH集群。本地MIT KDC通常部署在实用程序主机上。为了获得高可用性，其他复制的MIT KDC是可选的。
必须将所有集群主机配置为使用该krb5.conf文件使用本地MIT Kerberos领域。
必须在本地MIT KDC和Kerberos领域中创建所有服务和用户主体。
本地MIT KDC将同时验证服务主体（使用keytab文件）和用户主体（使用密码）。
Cloudera Manager连接到本地MIT KDC，以创建和管理在集群上运行的CDH服务的主体。为此，Cloudera Manager使用在设置过程中创建的管理员主体和密钥表。Kerberos向导已自动执行此步骤。有关详细信息，请参见使用向导启用Kerberos认证。有关手动创建管理员主体的信息，请参见如何配置集群以使用Kerberos进行认证。
本地MIT KDC管理员通常会创建所有其他用户主体。但是，Cloudera Manager Kerberos向导可以自动创建主体和密钥表文件。

优点	缺点
身份验证机制与企业的其余部分隔离。	这非常容易设置，特别是如果您使用Cloudera Manager Kerberos向导来自动创建和分发服务主体和密钥表文件。
这非常容易设置，特别是如果您使用Cloudera Manager Kerberos向导来自动创建和分发服务主体和密钥表文件。	用户和服务主体必须在本地MIT KDC中创建，这可能很耗时。
	本地MIT KDC可能是集群的单点故障，除非可以将复制的KDC配置为具有高可用性。
	本地MIT KDC是另一个要管理的身份验证系统。

具有Active Directory集成的本地MIT KDC

此方法使用集群本地的MIT KDC和Kerberos领域。但是，Active Directory将将访问集群的用户主体存储在中央领域中。用户必须先在此中央AD领域进行身份验证才能获得TGT，然后才能与集群上的CDH服务进行交互。请注意，CDH服务主体仅驻留在本地KDC领域中。

架构摘要：

MIT KDC和独特的Kerberos领域已本地部署到CDH集群。本地MIT KDC通常部署在实用程序主机上，并且其他复制的MIT KDC具有高可用性是可选的。
使用该krb5.conf文件，所有集群主机都配置了Kerberos领域（本地和中央AD）。默认领域应为本地MIT Kerberos领域。
服务主体应在本地MIT KDC和本地Kerberos领域中创建。Cloudera Manager连接到本地MIT KDC，以创建和管理在集群上运行的CDH服务的主体。为此，Cloudera Manager使用在安全设置期间创建的管理员主体和密钥表。Kerberos向导已自动执行此步骤。
必须从本地Kerberos领域到包含要求访问CDH集群的用户主体的中央AD领域建立单向跨领域信任。无需在中央AD领域中创建服务主体，也无需在本地领域中创建用户主体。

优点	缺点
本地MIT KDC充当中央Active Directory的防护对象，以防止CDH集群中的许多主机和服务。在大型集群中重新启动服务会创建许多同时进行的身份验证请求。如果Active Directory无法处理负载激增，则集群可以有效地引起分布式拒绝服务（DDOS）攻击。	本地MIT KDC可以是集群的单点故障（SPOF）。可以将复制的KDC配置为高可用性。
这非常容易设置，特别是如果您使用Cloudera Manager Kerberos向导来自动创建和分发服务主体和密钥表文件。 Active Directory管理员只需要在设置过程中参与配置跨域信任。	本地MIT KDC是另一个要管理的身份验证系统。
与中央Active Directory集成以进行用户主体身份验证可提供更完整的身份验证解决方案。
允许增量配置。可以使用本地MIT KDC独立和与Active Directory集成来配置和验证Hadoop安全性。

使用集中式Active Directory服务

这种方法使用中央Active Directory作为KDC。不需要本地KDC。在决定AD KDC部署之前，请确保您了解该决定的以下可能后果。

架构摘要：

所有服务和用户主体都在Active Directory KDC中创建。
所有集群主机都使用来配置中央AD Kerberos领域krb5.conf。
Cloudera Manager连接到Active Directory KDC，以创建和管理在集群上运行的CDH服务的主体。为此，Cloudera Manager使用具有在给定组织单位（OU）内创建其他帐户的特权的主体。（此步骤已由Kerberos向导自动执行。）
所有服务和用户主体均由Active Directory KDC进行身份验证。

注意：

如果无法在Active Directory KDC中使用所需特权创建Cloudera Manager管理员主体，则需要手动创建CDH服务主体。然后，应将相应的密钥表文件安全地存储在Cloudera Manager Server主机上。Cloudera Manager的“ 自定义Kerberos Keytab检索”脚本可用于从本地文件系统检索keytab文件。

Active Directory KDC的建议

为身份验证请求提供服务时涉及几个不同的子系统，包括密钥分发中心（KDC），身份验证服务（AS）和票证授予服务（TGS）。集群中的节点越多，提供的服务越多，这些服务与集群上运行的服务之间的流量就越大。

作为一般准则，Cloudera建议为集群中的每100个节点使用专用的Active Directory实例（Microsoft Server Domain Services）。但是，这只是一个宽松的准则。监视利用率并根据需要部署其他实例以满足需求。

默认情况下，Kerberos使用TCP进行客户端/服务器通信，这可以保证传递，但传递数据包的速度不如UDP。要覆盖此设置并让Kerberos在TCP之前先尝试UDP。

如果域控制器与集群不在同一子网上或被防火墙隔开，则此功能特别有用。

通常，Cloudera建议在与集群相同的子网上设置Active Directory域控制器（Microsoft服务器域服务），并且永远不要通过WAN连接进行设置。将集群与Active Directory域控制器上运行的KDC分开会导致大量延迟，并影响集群性能。

在将Active Directory用于Kerberos身份验证时，对集群操作进行故障排除需要对Microsoft Server Domain Services实例的管理访问权限。管理员可能需要在Microsoft Server KDC上启用Kerberos事件日志记录才能解决问题。

删除Cloudera Manager角色或节点需要手动删除关联的Active Directory帐户。Cloudera Manager无法从Active Directory删除条目。

与Active Directory的身份集成

在平台中启用Kerberos安全性的核心要求是用户在所有集群处理节点上均具有帐户。诸如Centrify或Quest Authentication Services（QAS）之类的商业产品可将所有集群主机集成在一起，以将用户和组解析到Active Directory。这些工具支持用户通过AD登录Linux主机时的自动Kerberos身份验证。对于未使用Active Directory的站点或希望使用开放源代码解决方案的站点，站点安全服务守护程序（SSSD）可以与AD或OpenLDAP兼容目录服务以及MIT Kerberos一起使用，以满足相同的需求。

对于第三方提供商，您可能必须从各自的供应商处购买许可证。此过程需要一些计划，因为要花费时间来获取这些许可证并将这些产品部署在集群上。当计算机加入AD域时，应注意确保身份管理产品不将服务主体名称（SPN）与主机主体相关联。例如，默认情况下，“集中化”将HTTP SPN与主机主体相关联。因此，当主机加入域时，应特别排除HTTP SPN。

您还需要在AD中完成以下设置任务：

Active Directory组织单位（OU）和OU用户 -应该在Active Directory中创建一个单独的OU，以及一个有权在该OU中创建其他帐户的帐户。
为AD启用SSL -Cloudera Manager应该能够通过LDAPS（TCP 636）端口连接到AD。
主体和密钥表 -在使用Kerberos向导设置的直接AD部署中，默认情况下，所有必需的主体和密钥表将由Cloudera Manager创建，部署和管理。但是，如果由于某种原因您不能允许Cloudera Manager管理直接到AD的部署，则应该在AD中为在每个主机上运行的每个服务手动创建唯一帐户，并且必须提供相同的keytab文件。这些帐户应将AD用户主体名称（UPN）设置为 service/fqdn@REALM，并将服务主体名称（SPN）设置为service/fqdn。keytab文件中的主体名称应为帐户的UPN。密钥表文件应遵循命名约定：servicename_fqdn.keytab。必须为它们在其上运行的每个主机创建以下主体和keytab文件：Hadoop用户（user：group）和Kerberos主体。
AD绑定帐户 -创建一个将在Hue，Cloudera Manager和Cloudera Navigator中用于LDAP绑定的AD帐户。
特权用户的 AD组-创建AD组并为授权用户，HDFS管理员和HDFS超级用户组添加成员。

授权用户–由需要访问集群的所有用户组成的组
HDFS管理员–将运行HDFS管理命令的用户组
HDFS超级用户–需要超级用户特权（即对HDFS中所有数据和目录的读/写访问权限）的用户组
不建议将普通用户放入HDFS超级用户组。相反，管理员将问题升级到的帐户应成为HDFS超级用户组的一部分。

用于基于角色访问Cloudera Manager和Cloudera Navigator的 AD组-创建AD组并将成员添加到这些组中，以便您以后可以配置对Cloudera Manager和Cloudera Navigator的基于角色的访问。
AD测试用户和组 -应该至少提供一个现有的AD用户和该用户所属的组，以测试授权规则是否按预期工作。