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" } 
  }
}

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

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 配置以确定他们是否应该加载委托令牌。

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

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

其次，elasticsearch-hadoop 的所有通用连接设置（如 es.nodes、es.ssl.enabled 等）必须在 本地 Hadoop 配置文件、本地 Spark 配置文件或命令行中指定。如果此处无法使用这些设置，则凭据提供程序将无法联系 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 在类路径中时，EsServiceCredentialProvider 将始终由 Spark 加载。如果在本地 Hadoop 配置中为 elasticsearch-hadoop 启用了 Kerberos 身份验证，则提供程序将尝试加载 Elasticsearch 的委托令牌，而不管这些令牌对于特定作业是否需要。

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

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