Kerberos

Elasticsearch for Apache Hadoop 只需要 一些设置 即可配置 Kerberos 身份验证。最好在您的 core-site.xml 配置中设置这些属性，以便可以在整个 Hadoop 部署中获取它们，就像为 Hadoop 中的服务启用安全选项一样。

<configuration>
    ...
    <property>
        <name>es.security.authentication</name>
        <value>kerberos</value>
    </property>
    <property>
        <name>es.net.spnego.auth.elasticsearch.principal</name>
        <value>HTTP/[email protected]</value>
    </property>
    ...
</configuration>

为将查询 Hive 的最终用户创建一个角色。在本例中，我们将为访问与 hive-index-* 匹配的索引创建一个简单的角色。我们所有的 Hive 用户最终都将使用此角色在 Elasticsearch 中读取、写入和更新索引。

PUT _security/role/hive_user_role 
{
  "run_as": [],
  "cluster": ["monitor", "manage_token"], 
  "indices": [
      {
        "names": [ "hive-index-*" ],  
        "privileges": [ "read", "write", "manage" ]
      }
  ]
}

现在已经创建了用户角色，我们必须将 Kerberos 用户主体映射到该角色。Elasticsearch 不知道 Kerberos 管理的主体的完整列表。因此，希望连接到 Elasticsearch 的每个主体都必须映射到身份验证后将被授予的角色列表。

POST /_security/role_mapping/hive_user_1_mapping
{
  "roles": [ "hive_user_role" ], 
  "enabled": true,
  "rules": {
    "field" : { "username" : "hive.user.1@REALM" } 
  }
}

将用户镜像到本机领域将允许 Elasticsearch 接受来自原始主体的身份验证请求，以及接受来自模拟用户的 Hive 的请求。您可以在本机领域中创建一个用户，如下所示

PUT /_security/user/hive.user.1 
{
  "enabled" : true,
  "password" : "swordfish", 
  "roles" : [ "hive_user_role" ], 
  "metadata" : {
    "principal" : "hive.user.1@REALM" 
  }
}

使用 Kerberos 主体的角色映射和用于模拟的本机用户配置 Elasticsearch 后，您必须创建一个 Hive 将用于模拟这些用户的角色。

PUT _security/role/hive_proxier
{
  "run_as": ["hive.user.1"] 
}

现在有了要模拟的用户以及可以模拟他们的角色，请确保将 Hive 主体映射到代理角色，以及它正在模拟的用户可能拥有的任何角色。这允许 Hive 主体创建和读取索引、文档或执行其模拟用户可能能够执行的任何其他操作。当 Hive 模拟用户时，它必须具有这些角色，否则它将无法完全模拟该用户。

POST /_security/role_mapping/hive_hiveserver2_mapping
{
  "roles": [
    "hive_user_role", 
    "hive_proxier" 
  ],
  "enabled": true,
  "rules": {
    "field" : { "username" : "hive/hiveserver2.address@REALM" } 
  }
}

Spark 凭据提供程序的所有实现都只使用来自少数几个地方的设置

不使用从用户代码配置的设置，因为必须为为特定 Spark 应用程序提交的所有作业运行一次提供程序。不能保证在加载提供程序之前运行用户代码。更复杂的是，只为凭据提供程序提供本地 Hadoop 配置，以确定它们是否应该加载委派令牌。

这些限制意味着为 Kerberos 身份验证配置 elasticsearch-hadoop 的设置需要位于特定位置

首先，必须在本地 Hadoop 配置文件中将 es.security.authentication 设置为*kerberos*。如果未在 Hadoop 配置中设置它，则凭据提供程序将假定要使用*simple*身份验证，并且不会获取委派令牌。

其次，必须在 本地 Hadoop 配置文件、本地 Spark 配置文件中或从命令行指定 elasticsearch-hadoop 的所有常规连接设置（如 es.nodes、es.ssl.enabled 等）。如果这些设置在此处不可用，则凭据提供程序将无法联系 Elasticsearch 以获取其所需的委派令牌。

$> bin/spark-submit \
    --class org.myproject.MyClass \
    --master yarn \
    --deploy-mode cluster \
    --jars path/to/elasticsearch-hadoop.jar \
    --conf 'spark.es.nodes=es-node-1,es-node-2,es-node-3' 
    --conf 'spark.es.ssl.enabled=true'
    --conf 'spark.es.net.spnego.auth.elasticsearch.principal=HTTP/_HOST@REALM' 
    path/to/jar.jar

由于流式作业预期会持续运行而不会停止，因此您应该配置 Spark，以便凭据提供程序可以在原始令牌过期之前获取新令牌。

配置 Spark 以获取新令牌不同于配置 YARN 以续订和取消令牌。 YARN 只能将现有令牌续订至其最长生存期。 Elasticsearch 的令牌不可续订。相反，它们的生存期为 7 天。 7 天过后，令牌就会过期。为了使正在进行的流式作业能够继续运行而不会中断，必须获取全新的令牌并将其发送到工作任务。 Spark 具有在原始令牌生存期结束后自动获取和分发全新令牌的功能。

在 YARN 上提交 Spark 应用程序时，用户可以向 spark-submit 命令提供主体和密钥表文件。 Spark 将使用这些凭据登录，而不是依赖于当前用户的本地 Kerberos TGT 缓存。如果任何委派令牌即将过期，则在当前令牌完全过期之前，已加载的凭据提供程序将有机会使用给定的主体和密钥表获取新令牌。任何新令牌都会由 Spark 自动分发到 YARN 集群上的容器。

$> bin/spark-submit \
    --class org.myproject.MyClass \
    --master yarn \ 
    --deploy-mode cluster \ 
    --jars path/to/elasticsearch-hadoop.jar \
    --principal client@REALM 
    --keytab path/to/keytab.kt \ 
    path/to/jar.jar

当 elasticsearch-hadoop 位于类路径上时，Spark 始终会加载 EsServiceCredentialProvider。如果在本地 Hadoop 配置中为 elasticsearch-hadoop 启用了 Kerberos 身份验证，则无论该特定作业是否需要 Elasticsearch 的委派令牌，提供程序都将尝试加载它们。

建议您不要将 elasticsearch-hadoop 库添加到未配置为连接或交互 Elasticsearch 的作业中。这是避免不相关的作业因无法连接到 Elasticsearch 而启动失败的最简单方法。

如果您发现自己无法轻松地从不需要与 Elasticsearch 交互的作业的类路径中删除 elasticsearch-hadoop，则可以通过在启动时设置属性来显式禁用凭据提供程序。要设置的属性取决于您的 Spark 版本