对于任何计算环境来讲，身份验证是最基本的安全要求。简单来说，用户和服务必须先向系统证明其身份（身份验证），然后才能在授权范围内使用系统功能。身份验证和授权携手并进，以保护系统资源。授权有多种方式处理，从访问控制列表（ACL）到HDFS扩展的ACL，再到使用Ranger的基于角色的访问控制（RBAC）。
几种不同的机制一起工作以对集群中的用户和服务进行身份验证。这些取决于集群上配置的服务。大多数CDH组件，包括Apache Hive、Hue和Apache Impala，都可以使用Kerberos进行身份验证。无论是MIT KDC 还是Microsoft Active Directory Kerberos的实现，都可以和Cloudera集群集成一起使用。
另外，可以在LDAP兼容的身份服务（例如OpenLDAP和Windows Server的核心组件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集成无关的一项重要的首要任务，而与部署模型无关。
Kerberos概述
简而言之，Kerberos是一种身份验证协议，它依赖于加密机制来处理客户端和服务器之间的交互的请求，从而极大地降低了模拟的风险。密码既不存储在本地，也不通过网络明文发送。用户在登录其系统时输入的密码用于解锁本地机制，然后在与受信任的第三方的后续交互中使用该机制来向用户授予票证（有限的有效期），该票证用于根据请求进行身份验证服务。在客户端和服务器进程相互证明各自的身份之后，对通信进行加密以确保隐私和数据完整性。
受信任的第三方是Kerberos密钥分发中心（KDC），它是Kerberos操作的焦点，它也为系统提供身份验证服务和票证授予服务（TGS）。简要地说，TGS向请求的用户或服务发行票证，然后将票证提供给请求的服务，以证明用户（或服务）在票证有效期内的身份（默认为10小时）。Kerberos有很多细微差别，包括定义用于标识系统用户和服务的主体、票证续订、委托令牌处理等。
此外，这些过程在很大程度上完全透明地发生。例如，集群的业务用户只需在登录时输入密码，票证处理、加密和其他详细信息就会在后台自动进行。此外，由于使用了票证和Kerberos基础结构中的其他机制，用户不仅通过了单个服务目标，还通过了整个网络的身份验证。
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使用在设置过程中创建的管理员主体和Keytab。Kerberos向导已经自动执行此步骤。
- 本地的MIT KDC管理员通常会创建所有其他用户主体。但是，Cloudera Manager Kerberos向导可以自动创建主体和Keytab文件。
优点 | 缺点 |
|---|---|
身份验证机制与企业的其余身份验证机制部分隔离。 | 该机制未与中央认证系统集成。 |
这非常容易设置，特别是如果您使用Cloudera Manager Kerberos向导来自动创建和分发服务主体和Keytab文件。 | 必须在本地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使用在安全设置期间创建的管理员主体和Keytab。Kerberos向导已自动执行此步骤。
- 必须从本地Kerberos领域到包含要求访问CDH集群的用户主体的中央AD领域建立单向跨领域信任。无需在中央AD领域中创建服务主体，也无需在本地领域中创建用户主体。
优点 | 缺点 |
|---|---|
本地MIT KDC充当中央Active Directory的防护对象，以防止CDH集群中的许多主机和服务。在大型集群中重新启动服务会创建许多同时进行的身份验证请求。如果Active Directory无法处理负载激增，则集群可以有效地引起分布式拒绝服务（DDOS）攻击。 | 本地MIT KDC可以是集群的单点故障（SPOF）。可以将复制的KDC配置为具有高可用性。 |
这非常容易设置，特别是如果您使用Cloudera Manager Kerberos向导来自动创建和分发服务主体和Keytab文件。Active Directory管理员只需要在设置过程中参与配置跨域信任。 | 本地MIT KDC是另一个要管理的身份验证系统。 |
与中央Active Directory集成以进行用户主体身份验证可提供更完整的身份验证解决方案。 | |
允许增量配置。可以独立于与Active Directory集成而使用本地MIT KDC配置和验证Hadoop安全性。 |
使用集中式的Active Directory服务
这种方法使用中央Active Directory作为KDC。不需要本地KDC。在决定AD KDC部署之前，请确保您了解该决定的以下可能后果。
架构摘要
- 所有服务和用户主体都在Active Directory KDC中创建。
- 所有集群主机均使用krb5.conf来配置中央AD Kerberos领域。
- Cloudera Manager连接到Active Directory KDC，以创建和管理在集群上运行的CDH服务的主体。为此，Cloudera Manager使用有权在给定组织单位（OU）内创建其他帐户的主体。（此步骤已由Kerberos向导自动执行。）
- 所有服务和用户主体均由Active Directory KDC进行身份验证。
注意
如果无法在Active Directory KDC中使用所需特权创建Cloudera Manager管理员主体，则需要手动创建CDH服务主体。然后应将相应的Keytab文件安全地存储在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，请如下修改Kerberos配置文件（krb5.conf）：
[libdefaults]udp_preference_limit = 1...如果域控制器与集群不在同一子网中，或者被防火墙隔开，则这特别有用。
通常，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）与主机主体相关联。例如，默认情况下，Centrify将HTTP SPN与主机主体相关联。因此，当主机加入域时，应特别排除HTTP SPN。
您还需要在AD中完成以下设置任务：
- Active Directory组织单位（OU）和OU用户 -应该在Active Directory中创建一个单独的OU，以及一个有权在该OU中创建其他帐户的帐户。
- 为AD启用SSL -Cloudera Manager应该能够通过LDAPS（TCP 636）端口连接到AD。
- 主体和Keytab-在使用Kerberos向导设置的直连AD部署中，默认情况下，所有必需的主体和Keytab将由Cloudera Manager创建、部署和管理。但是，如果由于某种原因您不能允许Cloudera Manager管理直接到AD的部署，则应该在AD中为在每个主机上运行的每个服务手动创建唯一帐户，并且必须为其提供相同的keytab文件。这些帐户应将AD用户主体名称（UPN）设置为service/fqdn@REALM，并将服务主体名称（SPN）设置为service/fqdn。keytab文件中的主体名称应为帐户的UPN。keytab文件应遵循命名约定：servicename_fqdn.keytab。必须为它们运行的每个主机创建以下主体和keytab文件：
- 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用户和该用户所属的组，以测试授权规则是否按预期工作。
使用TLS / SSL进行安全的Keytab分发
Kerberos keytab文件在Cloudera Manager集群中的主机之间，Cloudera Manager Server和Cloudera Manager Agent主机之间传输。为了确保此敏感数据的安全，请配置Cloudera Manager服务器和Cloudera Manager代理主机以使用TLS / SSL进行加密通信。
使用向导或手动过程来配置Kerberos身份验证
Cloudera不提供Kerberos实现，而是使用现有的Kerberos部署来认证服务和用户。Kerberos服务器可以设置为专门供集群使用（例如Local MIT KDC），也可以是组织中其他应用程序使用的分布式Kerberos部署。
无论采用哪种部署模式，都可以在配置集群使用集群之前使用Kerberos实例。此外，如上所述，集群本身也应该是可运行的，并且理想情况下，应配置为对Cloudera Manager服务器和Cloudera Manager代理主机使用TLS / SSL。
当准备好将集群与组织的MIT KDC或Active Directory KDC集成时，可以使用Cloudera Manager Server中提供的向导或遵循以下手动过程来实现。
集群组件使用的身份验证机制
组件或产品 | 支持的认证机制 |
|---|---|
Accumulo | Kerberos (partial) |
Backup and Disaster Recovery | Kerberos (用于对Cloudera Manager进行身份验证以保护受Kerberos保护的服务), LDAP, SAML |
Cloudera Manager | Kerberos (用于对Cloudera Manager进行身份验证以保护受Kerberos保护的服务), LDAP, SAML |
Cloudera Navigator | Active Directory, OpenLDAP, SAML |
HBase | Kerberos, user-based authentication required for HBase Thrift and REST clients |
HDFS | Kerberos, SPNEGO (HttpFS) |
HiveServer | None |
HiveServer2 | Kerberos, LDAP, 自定义/可插入身份验证 |
Hive Metastore | Kerberos |
Hue | Kerberos, LDAP, SAML, 自定义/可插入身份验证 |
Impala | Kerberos, LDAP, SPNEGO (Impala Web Console) |
Kudu | Kerberos |
MapReduce | Kerberos (also see HDFS) |
Oozie | Kerberos, SPNEGO |
Pig | Kerberos |
Search | Kerberos, SPNEGO |
Spark | Kerberos |
Sqoop | Kerberos |
YARN | Kerberos (also see HDFS) |
Zookeeper | Kerberos |
原文链接：https://docs.cloudera.com/cdp-private-cloud-base/7.1.5/security-overview/topics/cm-security-authentication-overview.html
