Kerberos

Apache Hadoop 的 Elasticsearch 只需要一些设置来配置 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" 
  }
}

在您配置 Elasticsearch 时，为您的 Kerberos 主体和用于模拟的本地用户创建角色映射后，您必须创建一个 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 命令提供 principal 和 keytab 文件。Spark 将使用这些凭证登录，而不是依赖于当前用户的本地 Kerberos TGT 缓存。如果任何委托令牌即将过期，加载的凭证提供程序将有机会在使用给定的 principal 和 keytab 时获取新的令牌，然后当前令牌完全过期。任何新令牌都会由 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

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

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

如果你发现自己处于无法轻易从不需要与 Elasticsearch 交互的作业的 classpath 中删除 elasticsearch-hadoop 的境地，那么你可以通过在启动时设置属性来显式禁用凭证提供程序。要设置的属性取决于你的 Spark 版本