Kerberos 认证

编辑

您可以配置 Elastic Stack 安全功能以支持 Kerberos V5 认证,这是一种行业标准协议,用于在 Elasticsearch 中对用户进行身份验证。

您不能使用 Kerberos 领域来对传输网络层进行身份验证。

要使用 Kerberos 对用户进行身份验证,您需要配置一个 Kerberos 领域并将用户映射到角色。有关领域设置的更多信息,请参阅 Kerberos 领域设置

关键概念

编辑

在设置 Kerberos 领域时,您会遇到一些术语和概念。

kdc
密钥分发中心。一种颁发 Kerberos 票证的服务。
主体

Kerberos 主体是 Kerberos 可以为其分配票证的唯一身份。它可以用来识别用户或服务器提供的服务。

Kerberos V5 主体名称的格式为 primary/instance@REALM,其中 primary 是用户名。

instance 是一个可选字符串,用于限定 primary,并用斜杠 (/) 与 primary 分隔。对于用户来说,通常不使用它;对于服务主机,它是主机的完全限定域名。

REALM 是 Kerberos 领域。通常是大写形式的域名。典型用户主体的示例为 [email protected]。典型服务主体的示例为 HTTP/[email protected]

领域
领域定义了认证服务器有权对用户和服务进行认证的管理边界。
密钥表
存储主体和加密密钥对的文件。

任何拥有此文件读取权限的人都可以使用网络中的凭据访问其他服务,因此务必使用正确的文件权限来保护它。

krb5.conf
包含 Kerberos 配置信息的文件,例如默认领域名称、密钥分发中心 (KDC) 的位置、领域信息、域名到 Kerberos 领域的映射以及领域会话密钥加密类型的默认配置。
票据授予票据 (TGT)
TGT 是 Kerberos 认证服务器生成的认证票据。它包含一个加密的鉴别器。

配置 Kerberos 领域

编辑

Kerberos 用于保护服务,并使用基于票据的身份验证协议对用户进行身份验证。您可以将 Elasticsearch 配置为使用 Kerberos V5 身份验证协议(一种行业标准协议)对用户进行身份验证。在这种情况下,客户端必须出示 Kerberos 票据以进行身份验证。

在 Kerberos 中,用户首先通过认证服务进行身份验证,然后通过票据授予服务生成 TGT(票据授予票据)。然后将此票据提交给服务以进行身份验证。有关获取 TGT 的更多信息,请参阅您的 Kerberos 安装文档。Elasticsearch 客户端必须先获取 TGT,然后才能开始使用 Elasticsearch 进行身份验证的过程。

开始之前

编辑
  1. 部署 Kerberos。

    您必须在您的环境中设置 Kerberos 基础设施。

    Kerberos 需要许多外部服务才能正常运行,例如所有机器之间的时间同步以及域中的正常正向和反向 DNS 映射。有关更多详细信息,请参阅您的 Kerberos 文档。

    这些说明不包括设置和配置您的 Kerberos 部署。在提供示例时,它们与 MIT Kerberos V5 部署相关。有关更多信息,请参阅 MIT Kerberos 文档

  2. 配置 Java GSS。

    Elasticsearch 使用 Java GSS 框架支持 Kerberos 身份验证。为了支持 Kerberos 身份验证,Elasticsearch 需要以下文件

    • krb5.conf,一个 Kerberos 配置文件
    • 一个 keytab 文件,其中包含 Elasticsearch 服务主体的凭据

    配置要求取决于您的 Kerberos 设置。请参阅您的 Kerberos 文档以配置 krb5.conf 文件。

    有关 Java GSS 的更多信息,请参阅 Java GSS Kerberos 要求

  3. 为 HTTP 启用 TLS。

    如果您的 Elasticsearch 集群在生产模式下运行,则必须配置 HTTP 接口以使用 SSL/TLS,然后才能启用 Kerberos 身份验证。有关更多信息,请参阅 加密 Elasticsearch 的 HTTP 客户端通信

    此步骤对于通过 Kibana 支持 Kerberos 身份验证是必要的。对于直接针对 Elasticsearch Rest API 的 Kerberos 身份验证,不需要此步骤。

  4. 启用令牌服务

    Elasticsearch Kerberos 实现利用了 Elasticsearch 令牌服务。如果您在 HTTP 接口上配置了 TLS,则此服务将自动启用。可以通过在您的 elasticsearch.yml 文件中添加以下设置来显式配置它

    xpack.security.authc.token.enabled: true

    此步骤对于通过 Kibana 支持 Kerberos 身份验证是必要的。对于直接针对 Elasticsearch Rest API 的 Kerberos 身份验证,不需要此步骤。

创建 Kerberos 领域

编辑

要在 Elasticsearch 中配置 Kerberos 领域

  1. 配置 JVM 以查找 Kerberos 配置文件。

    Elasticsearch 使用 Java GSS 和 JAAS Krb5LoginModule 通过简单和受保护的 GSSAPI 协商机制 (SPNEGO) 机制支持 Kerberos 身份验证。Kerberos 配置文件 (krb5.conf) 提供了诸如默认领域、密钥分发中心 (KDC) 和 Kerberos 身份验证所需的其他配置详细信息等信息。当 JVM 需要某些配置属性时,它会尝试通过定位和加载此文件来查找这些值。配置文件路径的 JVM 系统属性是 java.security.krb5.conf。有关配置 JVM 系统属性的信息,请参阅 设置 JVM 选项。如果未指定此系统属性,则 Java 会根据约定尝试找到该文件。

    建议为 Elasticsearch 配置此系统属性。设置此属性的方法取决于您的 Kerberos 基础设施。有关更多详细信息,请参阅您的 Kerberos 文档。

    有关更多信息,请参阅 krb5.conf

  2. 为 Elasticsearch 节点创建密钥表。

    密钥表是一个存储主体和加密密钥对的文件。Elasticsearch 使用密钥表中的密钥来解密用户提供的票据。您必须使用 Kerberos 实现提供的工具为 Elasticsearch 创建密钥表。例如,一些创建密钥表的工具是 Windows 上的 ktpass.exe 和 MIT Kerberos 的 kadmin

  3. 将密钥表文件放在 Elasticsearch 配置目录中。

    确保此密钥表文件具有读取权限。此文件包含凭据,因此您必须采取适当的措施来保护它。

    Elasticsearch 在 HTTP 网络层上使用 Kerberos,因此每个 Elasticsearch 节点上都必须有一个 HTTP 服务主体的密钥表文件。服务主体名称必须具有 HTTP/[email protected] 格式。密钥表文件对于每个节点都是唯一的,因为它们包含主机名。Elasticsearch 节点可以充当客户端请求的任何主体,只要该主体及其凭据在配置的密钥表中找到即可。

  4. 创建 Kerberos 领域。

    要在 Elasticsearch 中启用 Kerberos 身份验证,您必须在领域链中添加一个 Kerberos 领域。

    您只能在 Elasticsearch 节点上配置一个 Kerberos 领域。

    要配置 Kerberos 领域,您需要在 elasticsearch.yml 配置文件中配置一些强制性领域设置和其他可选设置。在 xpack.security.authc.realms.kerberos 命名空间下添加领域配置。

    Kerberos 领域的常见配置如下

    xpack.security.authc.realms.kerberos.kerb1:
      order: 3
      keytab.path: es.keytab
      remove_realm_name: false

    从用户提供的票据中提取 username,其格式通常为 username@REALM。此 username 用于将角色映射到用户。如果领域设置 remove_realm_name 设置为 true,则会删除领域部分 (@REALM)。生成的 username 用于角色映射。

    有关可用领域设置的详细信息,请参阅 Kerberos 领域设置

  5. 重新启动 Elasticsearch
  6. 将 Kerberos 用户映射到角色。

    使用 kerberos 领域,您可以将 Kerberos 用户映射到角色。您可以使用 创建或更新角色映射 API 配置这些角色映射。您可以通过其 username 字段识别用户。

    以下示例使用角色映射 API 将 user@REALM 映射到角色 monitoringuser

    resp = client.security.put_role_mapping(
        name="kerbrolemapping",
        roles=[
            "monitoring_user"
        ],
        enabled=True,
        rules={
            "field": {
                "username": "user@REALM"
            }
        },
    )
    print(resp)
    const response = await client.security.putRoleMapping({
      name: "kerbrolemapping",
      roles: ["monitoring_user"],
      enabled: true,
      rules: {
        field: {
          username: "user@REALM",
        },
      },
    });
    console.log(response);
    POST /_security/role_mapping/kerbrolemapping
    {
      "roles" : [ "monitoring_user" ],
      "enabled": true,
      "rules" : {
        "field" : { "username" : "user@REALM" }
      }
    }

    如果您想支持 Kerberos 跨领域身份验证,您可能需要根据 Kerberos 领域名称映射角色。对于此类场景,以下角色映射可用的其他用户元数据:- kerberos_realm 将设置为 Kerberos 领域名称。- kerberos_user_principal_name 将设置为 Kerberos 票据中的用户主体名称。

    有关更多信息,请参阅 将用户和组映射到角色

    Kerberos 领域支持 授权领域 作为角色映射的替代方案。

为 Kerberos 配置 Kibana

编辑

如果您想使用 Kerberos 通过浏览器和 Kibana 进行身份验证,则需要在 Kibana 配置中启用相关的身份验证提供程序。请参阅 Kerberos 单点登录