Kibana 中的身份验证

通过在配置中指定身份验证提供程序（通常是各种类型）的优先级列表，可以同时启用多种身份验证机制。提供程序按升序进行咨询。确保每个配置的提供程序都有一个唯一的名称（例如，配置示例中的 basic1 或 saml1）和 order 设置。如果两个或多个提供程序具有相同的名称或 order，Kibana 将无法启动。

当配置了两个或多个提供程序时，您可以在登录选择器 UI 中选择要使用的提供程序。提供程序显示的顺序由 order 设置决定。可以使用 description、hint 和 icon 设置自定义特定提供程序条目的外观。

如果您不希望某个特定提供程序出现在登录选择器 UI 中（例如，仅支持第三方发起的登录），您可以使用 showInSelector 设置设置为 false 来隐藏它。但是，在这种情况下，提供程序将出现在提供程序链中，并且可能会根据其 order 在身份验证期间进行咨询。要禁用提供程序，请使用 enabled 设置。

以下是如何在处理多个身份验证提供程序时使您的 kibana.yml 和登录选择器 UI 看起来像

xpack.security.loginHelp: "**Help** info with a [link](...)"
xpack.security.authc.providers:
  basic.basic1:
    order: 0
    icon: "logoElasticsearch"
    hint: "Typically for administrators"
  saml.saml1:
    order: 1
    realm: saml1
    description: "Log in with SSO"
    icon: "https://my-company.xyz/saml-logo.svg"
  saml.saml2:
    order: 2
    realm: saml2
    showInSelector: false
  kerberos.kerberos1:
    order: 3
    enabled: false

有关更多信息，请参阅 身份验证安全设置。

要成功登录 Kibana，基本身份验证需要用户名和密码。基本身份验证默认启用，并且基于 Elasticsearch 提供的本机、LDAP 或 Active Directory 安全领域。基本身份验证提供程序使用 Kibana 提供的登录表单，并支持使用 Authorization 请求标头 Basic 方案进行身份验证。

有关基本身份验证和内置用户的更多信息，请参阅 用户身份验证。

令牌身份验证是 订阅功能。这允许用户使用与基本身份验证相同的 Kibana 提供的登录表单登录，并且基于 Elasticsearch 提供的本机安全领域或 LDAP 安全领域。令牌身份验证提供程序基于 Elasticsearch 令牌 API。

在配置 Kibana 之前，请确保在 Elasticsearch 中启用了令牌支持。有关更多信息，请参阅 Elasticsearch 令牌 API 文档。

要在 Kibana 中启用令牌身份验证提供程序，请在您的 kibana.yml 中设置以下值

xpack.security.authc.providers:
  token.token1:
    order: 0

从基本提供程序切换到令牌身份验证提供程序将使 Kibana 拒绝来自 curl 等应用程序的请求，这些应用程序通常使用 Authorization 请求标头与 Basic 方案进行身份验证。如果您仍然希望支持此类应用程序，您将不得不切换到使用 Bearer 方案与 由 Elasticsearch 令牌 API 创建的令牌，或者将 Basic 方案添加到 HTTP 身份验证 支持的方案列表中。

PKI 身份验证是 订阅功能。这允许用户使用 X.509 客户端证书登录 Kibana，这些证书必须在连接到 Kibana 时出示。证书必须首先在 Kibana TLS 层上被接受以进行身份验证，然后由 Elasticsearch PKI 领域进一步验证。PKI 身份验证提供程序依赖于 Elasticsearch 委托 PKI 身份验证 API 来交换 X.509 客户端证书以访问令牌。所有后续代表用户对 Elasticsearch API 的请求都将使用这些访问令牌进行身份验证。

在配置 Kibana 之前，请确保在 Elasticsearch 中启用了 PKI 领域，并配置为允许委托。有关更多信息，请参阅 配置 PKI 领域。

要在 Kibana 中启用 PKI 身份验证提供程序，您必须首先 配置 Kibana 以加密浏览器和 Kibana 服务器之间的通信。您还必须启用 TLS 客户端身份验证，并将用于签署客户端证书的证书颁发机构 (CA) 包含在您的 kibana.yml 中 Kibana 信任的 CA 列表中

server.ssl.certificateAuthorities: /path/to/your/cacert.pem
server.ssl.clientAuthentication: required
xpack.security.authc.providers:
  pki.pki1:
    order: 0

您还可以为同一个 Kibana 实例配置 PKI 和基本身份验证

server.ssl.clientAuthentication: optional
xpack.security.authc.providers:
  pki.pki1:
    order: 0
  basic.basic1:
    order: 1

请注意，当 server.ssl.clientAuthentication 设置为 required 时，即使用户想要使用用户名和密码进行身份验证，也会要求他们提供有效的客户端证书。这可能取决于安全策略，可能是或可能不是想要的。如果不是，则可以将 server.ssl.clientAuthentication 设置为 optional。在这种情况下，Kibana 仍然会请求客户端证书，但客户端不会被要求出示证书。在其他情况下，可能还需要 optional 客户端身份验证模式，例如，当 PKI 身份验证与 Reporting 一起使用时。

SAML 身份验证是单点登录 (SSO) 的一部分，是 订阅功能。这允许用户使用外部身份提供者（例如 Okta 或 Auth0）登录 Kibana。在 Kibana 中设置 SAML 之前，请确保在 Elasticsearch 中启用了 SAML 并进行了配置。请参阅 在 Elastic Stack 上配置 SAML 单点登录。

通过指定 Elasticsearch 中应使用哪个 SAML 领域来启用 SAML 身份验证

xpack.security.authc.providers:
  saml.saml1:
    order: 0
    realm: saml1

您可以通过直接导航到 Kibana URL 来通过 SAML SSO 登录 Kibana。如果您未经身份验证，您将被重定向到身份提供者进行登录。大多数身份提供者会维护一个长期会话。如果您使用同一身份提供者在同一浏览器中登录到其他应用程序，您将自动进行身份验证。唯一的例外是，如果 Elasticsearch 或身份提供者配置为强制您重新进行身份验证。这种登录场景称为服务提供者发起的登录。

还可以同时配置多个 SAML 身份验证提供程序。在这种情况下，您需要在登录选择器 UI 中选择要使用的提供程序。

xpack.security.authc.providers:
  saml.saml1:
    order: 0
    realm: saml1
    description: "Log in with Elastic"
  saml.saml2:
    order: 1
    realm: saml2
    description: "Log in with Auth0"

SAML 和基本身份验证编辑

您还可以为同一个 Kibana 实例配置 SAML 和基本身份验证。这可能是 Kibana 或 Elasticsearch 管理员的情况，他们的帐户未链接到 SSO 用户数据库

xpack.security.authc.providers:
  saml.saml1:
    order: 0
    realm: saml1
    description: "Log in with Elastic"
  basic.basic1:
    order: 1

基本身份验证仅在除了 saml 之外，还明确地在 xpack.security.authc.providers 设置中声明了 basic 身份验证提供程序时才受支持。

要支持 curl 等应用程序的基本身份验证，或者当请求中包含 Authorization: Basic base64(username:password) HTTP 标头时（例如，通过反向代理），请将 Basic 方案添加到 HTTP 身份验证 支持的方案列表中。

OpenID Connect (OIDC) 身份验证是单点登录 (SSO) 的一部分，是 订阅功能。与 SAML 类似，使用 OIDC 进行身份验证允许用户使用 OIDC 提供者（例如 Google 或 Okta）登录 Kibana。OIDC 也应该在 Elasticsearch 中进行配置。有关更多详细信息，请参阅 使用 OpenID Connect 配置对 Elastic Stack 的单点登录。

通过指定 Elasticsearch 中要使用的哪个 OIDC 领域来启用 OIDC 身份验证

xpack.security.authc.providers:
  oidc.oidc1:
    order: 0
    realm: oidc1

要使用第三方发起的 SSO，请将您的 OpenID 提供者配置为使用 /api/security/oidc/initiate_login 作为 Initiate Login URI。

还可以同时配置多个 OpenID Connect 身份验证提供程序。在这种情况下，您需要在登录选择器 UI 中选择要使用的提供程序。

xpack.security.authc.providers:
  oidc.oidc1:
    order: 0
    realm: oidc1
    description: "Log in with Elastic"
  oidc.oidc2:
    order: 1
    realm: oidc2
    description: "Log in with Auth0"

OpenID Connect 和基本身份验证edit

您也可以为同一个 Kibana 实例配置 OpenID Connect 和基本身份验证。这可能适用于 Kibana 或 Elasticsearch 管理员，他们的帐户未链接到 SSO 用户数据库。

xpack.security.authc.providers:
  oidc.oidc1:
    order: 0
    realm: oidc1
    description: "Log in with Elastic"
  basic.basic1:
    order: 1

仅当 basic 身份验证提供程序在 xpack.security.authc.providers 设置中显式声明时，才支持基本身份验证，此外还有 oidc。

要支持 curl 等应用程序的基本身份验证，或者当请求中包含 Authorization: Basic base64(username:password) HTTP 标头时（例如，通过反向代理），请将 Basic 方案添加到 HTTP 身份验证 支持的方案列表中。

单点登录提供程序详细信息edit

以下部分适用于 SAML 单点登录 和 OpenID Connect 单点登录

访问令牌和刷新令牌edit

用户使用 SSO 登录 Kibana 后，无论是使用 SAML 还是 OpenID Connect，Elasticsearch 都会颁发访问令牌和刷新令牌，Kibana 会对这些令牌进行加密并将其存储为其自身会话的一部分。这样，用户就不会被重定向到身份提供者以处理每个需要身份验证的请求。这也意味着 Kibana 会话依赖于 xpack.security.session.idleTimeout 和 xpack.security.session.lifespan 设置，如果会话过期，用户将自动注销。存储在会话中的访问令牌可能会过期，在这种情况下，Kibana 会自动使用一次性刷新令牌对其进行续订，并将该令牌存储在同一个会话中。

Kibana 只能在收到需要身份验证的请求时才能确定访问令牌是否已过期。如果访问令牌和刷新令牌都已过期（例如，在 24 小时不活动后），Kibana 会启动新的“握手”，并将用户重定向到外部身份验证提供者（SAML 身份提供者或 OpenID Connect 提供者）。根据 Elasticsearch 和外部身份验证提供者的配置，可能会要求用户重新输入凭据。

如果 Kibana 无法将用户重定向到外部身份验证提供者（例如，对于 AJAX/XHR 请求），则错误表明访问令牌和刷新令牌都已过期。重新加载当前 Kibana 页面可以解决此错误。

本地注销和全局注销edit

在注销期间，Kibana 会话和 Elasticsearch 访问/刷新令牌对都会失效。这称为“本地”注销。

如果外部身份验证提供者支持，并且 Elasticsearch 未明确禁用，Kibana 还可以启动“全局”注销或单点注销。在这种情况下，用户将被重定向到外部身份验证提供者，以注销与活动提供者会话关联的所有应用程序。

Kerberos 身份验证是单点登录 (SSO) 的一部分，是 订阅功能。在 Kibana 中设置 Kerberos 之前，请确保在 Elasticsearch 中启用并配置 Kerberos。请参阅 Kerberos 身份验证。

接下来，要在 Kibana 中启用 Kerberos，您需要在 kibana.yml 配置文件中启用 Kerberos 身份验证提供程序，如下所示

xpack.security.authc.providers:
  kerberos.kerberos1:
    order: 0

您可能希望能够使用基本身份验证提供程序进行身份验证，作为辅助机制，或者在为堆栈设置 Kerberos 时进行身份验证。

xpack.security.authc.providers:
  kerberos.kerberos1:
    order: 0
    description: "Log in with Kerberos"
  basic.basic1:
    order: 1

匿名身份验证允许用户在无需提供凭据的情况下访问 Kibana。如果您希望用户在将仪表板嵌入到其他应用程序中或在内部网络中设置演示 Kibana 实例时跳过登录步骤，这将非常有用，同时仍保持其他安全功能完好无损。

要在 Kibana 中启用匿名身份验证，您必须指定匿名服务帐户 Kibana 应在内部使用以对匿名请求进行身份验证的凭据。

您必须拥有一个可以使用用户名和密码对 Elasticsearch 进行身份验证的用户帐户，例如来自 Native 或 LDAP 安全域，以便您可以使用这些凭据来模拟匿名用户。以下是您的 kibana.yml 可能的样子

xpack.security.authc.providers:
  anonymous.anonymous1:
    order: 0
    credentials:
      username: "anonymous_service_account"
      password: "anonymous_service_account_password"

匿名访问和其他类型的身份验证edit

除了匿名访问之外，您还可以在 Kibana 中配置更多身份验证提供程序。在这种情况下，登录选择器会显示一个可配置的 以访客身份继续 选项，用于匿名访问。

xpack.security.authc.providers:
  basic.basic1:
    order: 0
  anonymous.anonymous1:
    order: 1
    credentials:
      username: "anonymous_service_account"
      password: "anonymous_service_account_password"

匿名访问和嵌入edit

匿名访问最受欢迎的用例之一是，当您将 Kibana 嵌入到其他应用程序中时，不想强制用户登录以查看它。如果您将 Kibana 配置为使用匿名访问作为唯一的身份验证机制，则在嵌入 Kibana 时无需执行任何特殊操作。

有关如何嵌入的信息，请参阅 将 Kibana 内容嵌入网页。

匿名访问会话edit

Kibana 为每个匿名用户维护一个单独的 会话，就像它对所有其他身份验证机制所做的那样。

您可以配置 会话空闲超时 和 会话生存期，用于匿名会话，与您对任何其他会话所做的一样，唯一的例外是默认情况下，匿名会话的空闲超时被明确禁用。全局 xpack.security.session.idleTimeout 设置不会影响匿名会话。要更改匿名会话的空闲超时，您必须配置提供程序级别的 xpack.security.authc.providers.anonymous.<provider-name>.session.idleTimeout 设置。

HTTP 协议提供了一个简单的身份验证框架，客户端可以使用该框架提供身份验证信息。它使用不区分大小写的令牌作为标识身份验证方案的方法，然后是通过该方案实现身份验证所需的附加信息。

这种类型的身份验证通常对需要身份验证的机器对机器交互很有用，并且不需要或不可能进行人工干预。在许多情况下，HTTP 身份验证支持对 Kibana 用户也很有用。

默认情况下，Kibana 支持 ApiKey 身份验证方案以及当前启用的身份验证提供程序支持的任何方案。例如，当启用基本身份验证提供程序时，Basic 身份验证方案会自动得到支持，或者当启用任何基于令牌的身份验证提供程序（令牌、SAML、OpenID Connect、PKI 或 Kerberos）时，Bearer 方案会自动得到支持。但也可以在 kibana.yml 配置文件中添加对任何其他身份验证方案的支持，如下所示

xpack.security.authc.http.schemes: [apikey, bearer, basic, something-custom]

使用此配置，您可以使用 ApiKey、Bearer、Basic 或 Something-Custom HTTP 方案（不区分大小写）向 Kibana 发送带有 Authorization 标头的请求。在幕后，Kibana 会将此标头中继到 Elasticsearch，然后 Elasticsearch 会使用标头中的凭据对请求进行身份验证。

嵌入内容身份验证edit

创建仪表板或可视化后，您可能希望与同事或朋友共享它。最简单的方法是共享仪表板或可视化的直接链接。但是，某些用户可能无法访问您的 Kibana。使用 Kibana 嵌入功能，您可以在公司内部网站或个人网页上显示您在 Kibana 中创建的内容。

为了最大程度地降低安全风险，使用 iframe 进行嵌入需要仔细考虑。默认情况下，现代 Web 浏览器会强制执行 同源策略 以限制框架页面的行为。当您的集群上启用了 Elastic Stack 安全功能时，请确保浏览器可以将会话 Cookie 传输到 Kibana 服务器。您需要注意的设置是 xpack.security.sameSiteCookies。为了支持现代浏览器，您必须将其设置为 None

xpack.security.sameSiteCookies: "None"

有关可能的值和影响的更多信息，请参阅 xpack.security.sameSiteCookies。有关 iframe 和 Cookie 的更多信息，请参阅 iframe 和 SameSite Cookie。

如果您将 Kibana 嵌入支持使用 SAML、OpenID Connect、Kerberos 或 PKI 进行单点登录 (SSO) 的网站，强烈建议将 Kibana 配置为 SSO 设置的一部分。在单一且配置正确的安全域中运行，可以为您提供最安全、最无缝的用户体验。

如果您启用了多个身份验证提供程序，并且希望在嵌入除仪表板和可视化之外的任何内容时自动登录匿名用户，则需要将 auth_provider_hint=<anonymous-provider-name> 查询字符串参数添加到您要嵌入的 Kibana URL。

例如，如果您编写 iframe 代码来嵌入 Kibana，它可能看起来像这样

<iframe src="https://127.0.0.1:5601/app/monitoring#/elasticsearch/nodes?embed=true&_g=(....)" height="600" width="800"></iframe>

要使此 iframe 自动利用匿名访问，您需要修改 src iframe 属性中的 Kibana 链接，使其看起来像这样

<iframe src="https://127.0.0.1:5601/app/monitoring?auth_provider_hint=anonymous1#/elasticsearch/nodes?embed=true&_g=(....)" height="600" width="800"></iframe>

有关更多信息，请参阅 嵌入代码。