Kibana 中的身份验证

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

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

如果您不希望特定提供程序在登录选择器 UI 上显示（例如，仅支持第三方发起的登录），可以使用设置为false的showInSelector设置将其隐藏。但是，在这种情况下，提供程序会显示在提供程序链中，并且可能会根据其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 提供的 Native、LDAP 或 Active Directory 安全领域。基本身份验证提供程序使用 Kibana 提供的登录表单，并支持使用Authorization请求标头Basic方案进行身份验证。

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

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

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

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

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

从基本身份验证提供程序切换到令牌身份验证提供程序将导致 Kibana 拒绝来自应用程序（如curl）的请求，这些应用程序通常使用带有Basic方案的Authorization请求标头进行身份验证。如果您仍然想支持此类应用程序，则必须切换为使用Elasticsearch 令牌 API 创建的带有令牌的Bearer方案，或将Basic方案添加到HTTP 身份验证支持的方案列表中。

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

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

要在 Kibana 中启用 PKI 身份验证提供程序，您必须首先配置 Kibana 以加密浏览器和 Kibana 服务器之间的通信。您还必须启用 TLS 客户端身份验证，并在您的kibana.yml中将用于签署客户端证书的证书颁发机构 (CA) 包括到 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 身份验证与报告结合使用时。

SAML 身份验证是单点登录 (SSO) 的一部分，是一项订阅功能。这允许用户使用外部身份提供程序（如 Okta 或 Auth0）登录 Kibana。确保在 Elasticsearch 中启用并配置了 SAML，然后再在 Kibana 中进行设置。请参阅在 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"

您还可以为同一 Kibana 实例配置 SAML 和基本身份验证。对于其帐户未链接到 SSO 用户数据库的 Kibana 或 Elasticsearch 管理员，可能会出现这种情况

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

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

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

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

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

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

要使用第三方发起的 SSO，请配置您的 OpenID 提供程序以将/api/security/oidc/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"

您还可以为同一 Kibana 实例配置 OpenID Connect 和基本身份验证。对于其帐户未链接到 SSO 用户数据库的 Kibana 或 Elasticsearch 管理员，可能会出现这种情况

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

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

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

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

一旦用户使用 SSO（使用 SAML 或 OpenID Connect）登录到 Kibana，Elasticsearch 会颁发访问令牌和刷新令牌，Kibana 会对其进行加密并将其存储为自身会话的一部分。这样，对于每个需要身份验证的请求，用户无需重定向到身份提供程序。这也意味着 Kibana 会话取决于 xpack.security.session.idleTimeout 和 xpack.security.session.lifespan 设置，如果会话过期，用户将自动注销。存储在会话中的访问令牌可能会过期，在这种情况下，Kibana 将使用一次性刷新令牌自动续订它，并将其存储在同一会话中。

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

如果 Kibana 无法将用户重定向到外部身份验证提供程序（例如，对于 AJAX/XHR 请求），则错误会指示访问令牌和刷新令牌均已过期。重新加载当前 Kibana 页面可以修复此错误。

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

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

Kerberos 身份验证是单点登录 (SSO) 的一部分，这是一项订阅功能。在 Kibana 中进行设置之前，请确保已在 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 的用户帐户，例如来自本机或 LDAP 安全领域的用户帐户，这样您就可以使用这些凭据来模拟匿名用户。以下是您的 kibana.yml 的外观

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

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

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

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

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

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 方案（不区分大小写）使用 Authorization 标头向 Kibana 发送请求。在底层，Kibana 会将此标头转发到 Elasticsearch，然后 Elasticsearch 会使用标头中的凭据对请求进行身份验证。

创建仪表板或可视化效果后，您可能希望与您的同事或朋友共享它。最简单的方法是共享指向您的仪表板或可视化效果的直接链接。但是，某些用户可能无法访问您的 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 设置的一部分。在单个且配置正确的安全域中运行为您提供最安全和无缝的用户体验。

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

例如，如果您创建 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>

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