Elasticsearch：配置 TLS/SSL 和 PKI 身份验证

Posted 2021-10-26 中国社区官方博客

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Elasticsearch：配置 TLS/SSL 和 PKI 身份验证相关的知识，希望对你有一定的参考价值。

当为使用生产许可证运行的集群启用 Elasticsearch 安全性时，必须使用 TLS/SSL 进行传输通信，并且必须正确设置。此外，一旦启用安全性，与 Elasticsearch 集群的所有通信都必须经过身份验证，包括来自 Kibana 和/或应用程序服务器的通信。

Kibana 和/或应用程序服务器向 Elasticsearch 集群进行身份验证的最简单方法是在其配置文件或源代码中嵌入用户名和密码。但是，在许多组织中，禁止在此类位置存储用户名和密码。在这种情况下，一种替代方法是使用公钥基础设施 (PKI - Public Key Infrastructure)（客户端证书）对 Elasticsearch 集群进行身份验证。

配置安全性以及 TLS/SSL 和 PKI 起初似乎令人生畏，因此本博客提供了有关如何的分步说明：启用安全性；配置TLS/SSL；为内置用户设置密码；使用PKI进行认证；最后，如何使用 PKI 向 Elasticsearch 集群验证 Kibana。

启用安全

首先，我们按照我之前的教程来安装好 Elasticsearch 及 Kibana。我先直接按照默认的方式来进行安装，不做任何的配置：

接下来，我们修改 elasticsearch.yml 以及 kibana.ym 配置文件来完成安全的配置。详细的步骤我们可以参考我之前的文章 “Elasticsearch：设置 Elastic 账户安全”。请注意：如果你是针对多个节点的配置，那么你不需要在 elasticsearch.yml 中配置 discovery.type: single-node。我们需要记住超级用户 elastic 的密码以便在一下的步骤中使用。

等我们完成这一步，我们会发现，我们在 Kibana 的配置文件中还是使用如下类似的用户名及密码把这些安全的信息暴露在外：

config/kibana.yml

elasticsearch.username: "kibana_system"
elasticsearch.password: "password"

我们希望在如下的步骤中尽量不要这么做，因为这样的做法可能会造成安全的泄露。

TLS/SSL 加密

Elasticsearch 有两个级别的通信，传输通信和 http 通信。传输协议用于 Elasticsearch 节点之间的内部通信，http 协议用于客户端到 Elasticsearch 集群的通信。保护这些通信的安全将在以下段落中讨论。

传输 TLS/SSL 加密

传输协议用于 Elasticsearch 集群内节点之间的通信。因为 Elasticsearch 集群中的每个节点对于集群中的其他节点来说既是客户端又是服务器，所以所有传输证书必须既是客户端证书又是服务器证书。如果 TLS/SSL 证书没有定义扩展密钥用法（extended key usage），那么它们已经是事实上的客户端和服务器证书。如果传输证书确实有扩展密钥使用部分（企业环境中使用的 CA 签名证书通常是这种情况），那么它们必须明确启用 clientAuth 和 serverAuth。

Elasticsearch 附带一个名为 elasticsearch-certutil 的实用程序，可用于生成自签名证书，该证书可用于加密 Elasticsearch 集群内的内部通信。

以下命令可用于生成可用于传输通信的证书，如 Elasticsearch 中的加密通信页面中所述：

$ bin/elasticsearch-certutil ca
This tool assists you in the generation of X.509 certificates and certificate
signing requests for use with SSL/TLS in the Elastic stack.

The 'ca' mode generates a new 'certificate authority'
This will create a new X.509 certificate and private key that can be used
to sign certificate when running in 'cert' mode.

Use the 'ca-dn' option if you wish to configure the 'distinguished name'
of the certificate authority

By default the 'ca' mode produces a single PKCS#12 output file which holds:
    * The CA certificate
    * The CA's private key

If you elect to generate PEM format certificates (the -pem option), then the output will
be a zip file containing individual files for the CA certificate and private key

Please enter the desired output file [elastic-stack-ca.p12]: 
Enter password for elastic-stack-ca.p12 :

在上面，我们打入两个 enter。上面的命令在当前目录下生产一个叫做 elastic-stack-ca.p12 的文件。

$ pwd
/Users/liuxg/elastic0/elasticsearch-7.15.0
$ ls
LICENSE.txt          config               lib
NOTICE.txt           data                 logs
README.asciidoc      elastic-stack-ca.p12 modules
bin                  jdk.app              plugins

然后，我们打入如下的命令：

$ bin/elasticsearch-certutil cert --ca elastic-stack-ca.p12
This tool assists you in the generation of X.509 certificates and certificate
signing requests for use with SSL/TLS in the Elastic stack.

The 'cert' mode generates X.509 certificate and private keys.
    * By default, this generates a single certificate and key for use
       on a single instance.
    * The '-multiple' option will prompt you to enter details for multiple
       instances and will generate a certificate and key for each one
    * The '-in' option allows for the certificate generation to be automated by describing
       the details of each instance in a YAML file

    * An instance is any piece of the Elastic Stack that requires an SSL certificate.
      Depending on your configuration, Elasticsearch, Logstash, Kibana, and Beats
      may all require a certificate and private key.
    * The minimum required value for each instance is a name. This can simply be the
      hostname, which will be used as the Common Name of the certificate. A full
      distinguished name may also be used.
    * A filename value may be required for each instance. This is necessary when the
      name would result in an invalid file or directory name. The name provided here
      is used as the directory name (within the zip) and the prefix for the key and
      certificate files. The filename is required if you are prompted and the name
      is not displayed in the prompt.
    * IP addresses and DNS names are optional. Multiple values can be specified as a
      comma separated string. If no IP addresses or DNS names are provided, you may
      disable hostname verification in your SSL configuration.

    * All certificates generated by this tool will be signed by a certificate authority (CA)
      unless the --self-signed command line option is specified.
      The tool can automatically generate a new CA for you, or you can provide your own with
      the --ca or --ca-cert command line options.

By default the 'cert' mode produces a single PKCS#12 output file which holds:
    * The instance certificate
    * The private key for the instance certificate
    * The CA certificate

If you specify any of the following options:
    * -pem (PEM formatted output)
    * -keep-ca-key (retain generated CA key)
    * -multiple (generate multiple certificates)
    * -in (generate certificates from an input file)
then the output will be be a zip file containing individual certificate/key files

Enter password for CA (elastic-stack-ca.p12) : 
Please enter the desired output file [elastic-certificates.p12]: 
Enter password for elastic-certificates.p12 : 

Certificates written to /Users/liuxg/elastic0/elasticsearch-7.15.0/elastic-certificates.p12

This file should be properly secured as it contains the private key for 
your instance.

This file is a self contained file and can be copied and used 'as is'
For each Elastic product that you wish to configure, you should copy
this '.p12' file to the relevant configuration directory
and then follow the SSL configuration instructions in the product guide.

For client applications, you may only need to copy the CA certificate and
configure the client to trust this certificate.

在上面的命令中，我们打入三个 enter 键。上面的命令在当前的目录中生产一个叫做 elastic-certificates.p12 的文件：

$ pwd
/Users/liuxg/elastic0/elasticsearch-7.15.0
$ ls
LICENSE.txt              data                     logs
NOTICE.txt               elastic-certificates.p12 modules
README.asciidoc          elastic-stack-ca.p12     plugins
bin                      jdk.app
config                   lib

一旦执行了上述命令，我们将拥有可用于加密通信的 TLS/SSL 证书。

新创建的证书应复制到位于 config 目录中名为 certs 的子目录中。然后将在 elasticsearch.yml 文件中指定证书，如下所示：

$ pwd
/Users/liuxg/elastic0/elasticsearch-7.15.0
$ tree -L 2 ./config/
./config/
├── certs
│   └── elastic-certificates.p12
├── elasticsearch.keystore
├── elasticsearch.yml
├── jvm.options
├── jvm.options.d
├── log4j2.properties
├── role_mapping.yml
├── roles.yml
├── users
└── users_roles

我们在 config/elasticsearch.yml 文件中填入如下的配置：

xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: certs/elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: certs/elastic-certificates.p12

现在重新启动 Elasticsearch 集群中的所有节点以使上述更改生效。

HTTP TLS/SSL 加密

对于 HTTP 通信，Elasticsearch 节点将仅充当服务器，因此可以使用服务器证书。HTTP TLS/SSL 证书不需要启用客户端身份验证。

Elasticsearch 中有两种重要的网络通信机制需要了解：

HTTP：用于 HTTP 通信绑定的地址和端口，这是 Elasticsearch REST API 公开的方式
transport：用于集群内节点之间的内部通信

在许多情况下，HTTP 通信的证书将由公司 CA 签署。值得注意的是，用于加密 HTTP 通信的证书可以完全独立于用于传输通信（transport communication）的证书。

为了减少本博客中的步骤数量，我们将使用与传输通信相同的证书进行 HTTP 通信。这些在 config/elasticsearch.yml 文件中指定如下：

xpack.security.http.ssl.enabled: true
xpack.security.http.ssl.keystore.path: certs/elastic-certificates.p12
xpack.security.http.ssl.truststore.path: certs/elastic-certificates.p12
xpack.security.http.ssl.client_authentication: optional

如果这个时候，我们重新启动 Elasticsearch 的话，那么我们可以看到如下的日志信息：

我们的 Kibana 再也连接不到 Elasticsearch 了。我们需要在如下的步骤中更进一步对它进行配置。

启用 PKI 身份验证

如配置 PKI 领域中所述，必须将以下内容添加到 config/elasticsearch.yml 文件中以允许 PKI 身份验证。

Elastic Stack 6.8 以前：

xpack.security.authc.realms.pki1.type: pki

Elastic Stack 7.x：

xpack.security.authc.realms.pki.pki1.order: 1

那么到目前位置，我们针对 config/elasticsearch.yml 所做的所有的配置总结如下：

config/elasticsearch.yml

xpack.security.enabled: true

xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: certs/elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: certs/elastic-certificates.p12

xpack.security.http.ssl.enabled: true
xpack.security.http.ssl.keystore.path: certs/elastic-certificates.p12
xpack.security.http.ssl.truststore.path: certs/elastic-certificates.p12
xpack.security.http.ssl.client_authentication: optional

xpack.security.authc.realms.pki.pki1.order: 1

我们需要把上面的配置添加到 config/elasticsearch.yml 文件的最后，并重新启动 Elasticsearch。当然，我们的 Kibana 如果没有做任何的修改，它是不会连接到 Elasticsearch 的。

创建客户端证书

将用于 PKI 身份验证的证书必须由与用于加密 HTTP 通信的证书相同的 CA 签名。通常，这些将由组织内的官方 CA 签署。但是，因为我们已经使用了自签名 CA，所以我们还使用我们之前保存为 elastic-stack-ca.p12 的相同自签名 CA 来签署我们的 HTTP 客户端证书。我们可以为客户端身份验证创建证书，如下所示：

$ pwd
/Users/liuxg/elastic0/elasticsearch-7.15.0
$ ls config/certs/
elastic-certificates.p12 elastic-stack-ca.p12
$ ./bin/elasticsearch-certutil cert --ca config/certs/elastic-stack-ca.p12 -name "CN=something,OU=Consulting Team,DC=mydomain,DC=com"
This tool assists you in the generation of X.509 certificates and certificate
signing requests for use with SSL/TLS in the Elastic stack.

The 'cert' mode generates X.509 certificate and private keys.
    * By default, this generates a single certificate and key for use
       on a single instance.
    * The '-multiple' option will prompt you to enter details for multiple
       instances and will generate a certificate and key for each one
    * The '-in' option allows for the certificate generation to be automated by describing
       the details of each instance in a YAML file

    * An instance is any piece of the Elastic Stack that requires an SSL certificate.
      Depending on your configuration, Elasticsearch, Logstash, Kibana, and Beats
      may all require a certificate and private key.
    * The minimum required value for each instance is a name. This can simply be the
      hostname, which will be used as the Common Name of the certificate. A full
      distinguished name may also be used.
    * A filename value may be required for each instance. This is necessary when the
      name would result in an invalid file or directory name. The name provided here
      is used as the directory name (within the zip) and the prefix for the key and
      certificate files. The filename is required if you are prompted and the name
      is not displayed in the prompt.
    * IP addresses and DNS names are optional. Multiple values can be specified as a
      comma separated string. If no IP addresses or DNS names are provided, you may
      disable hostname verification in your SSL configuration.

    * All certificates generated by this tool will be signed by a certificate authority (CA)
      unless the --self-signed command line option is specified.
      The tool can automatically generate a new CA for you, or you can provide your own with
      the --ca or --ca-cert command line options.

By default the 'cert' mode produces a single PKCS#12 output file which holds:
    * The instance certificate
    * The private key for the instance certificate
    * The CA certificate

If you specify any of the following options:
    * -pem (PEM formatted output)
    * -keep-ca-key (retain generated CA key)
    * -multiple (generate multiple certificates)
    * -in (generate certificates from an input file)
then the output will be be a zip file containing individual certificate/key files

Enter password for CA (config/certs/elastic-stack-ca.p12) : 
Please enter the desired output file [CN=something,OU=Consulting Team,DC=mydomain,DC=com.p12]: client.p12
Enter password for client.p12 : 

Certificates written to /Users/liuxg/elastic0/elasticsearch-7.15.0/client.p12

This file should be properly secured as it contains the private key for 
your instance.

This file is a self contained file and can be copied and used 'as is'
For each Elastic product that you wish to configure, you should copy
this '.p12' file to the relevant configuration directory
and then follow the SSL configuration instructions in the product guide.

For client applications, you may only need to copy the CA certificate and
configure the client to trust this certificate.

我们可以在当前的目录中发现如下的一个叫做 client.p12 的文件：

$ pwd
/Users/liuxg/elastic0/elasticsearch-7.15.0
$ ls
LICENSE.txt              config                   lib
NOTICE.txt               data                     logs
README.asciidoc          elastic-certificates.p12 modules
bin                      elastic-stack-ca.p12     plugins
client.p12               jdk.app

以上将创建一个名为 client.p12 的文件，其中包含对我们的 Elasticsearch 集群进行 PKI 身份验证所需的所有信息。但是，为了使用此证书，将其分解为私钥、公共证书和 CA 证书是有帮助的。这可以通过以下命令完成：

Private key

openssl pkcs12 -in client.p12 -nocerts -nodes > client.key

$ openssl pkcs12 -in client.p12 -nocerts -nodes > client.key
Enter Import Password:
$ ls
LICENSE.txt              client.p12               jdk.app
NOTICE.txt               config                   lib
README.asciidoc          data                     logs
bin                      elastic-certificates.p12 modules
client.key               elastic-stack-ca.p12     plugins

上面的命令将生成一个叫做 client.key 的文件。

Public Certificate

openssl pkcs12 -in client.p12 -clcerts -nokeys  > client.cer

$ openssl pkcs12 -in client.p12 -clcerts -nokeys  > client.cer
Enter Import Password:
$ ls
LICENSE.txt              client.p12               lib
NOTICE.txt               config                   logs
README.asciidoc          data                     modules
bin                      elastic-certificates.p12 plugins
client.cer               elastic-stack-ca.p12
client.key               jdk.app

上面文件将生成一个叫做 client.cer 的文件。

CA Certificate

$ openssl pkcs12 -in client.p12 -cacerts -nokeys -chain > client-ca.cer
Enter Import Password:
$ ls
LICENSE.txt              client.key               jdk.app
NOTICE.txt               client.p12               lib
README.asciidoc          config                   logs
bin                      data                     modules
client-ca.cer            elastic-certificates.p12 plugins
client.cer               elastic-stack-ca.p12

上述命令将生成一个叫做 client-ca.cer 的文件。

我们接下来在 Kibana 的安装目录中创建一个叫做 config/certs 的目录，并把上面创建的三个文件移到该目录中去：

$ pwd
/Users/liuxg/elastic0/kibana-7.15.0-darwin-x86_64
$ tree -L 2 config/certs
config/certs
├── client-ca.cer
├── client.cer
└── client.key

配置 Kibana 以对 Elasticsearch 进行身份验证

现在我们已经在 Elasticsearch 集群上启用了安全性，必须对与集群的通信进行身份验证。因此，如果我们计划使用 Kibana 与集群交互，那么我们必须启用安全性并配置 Kibana 以通过 HTTPS 以 kibana 用户身份向集群进行身份验证。由于我们尚未完全设置从 Kibana 到 Elasticsearch 集群的 PKI 身份验证，因此必须首先使用 kibana 用户和密码进行身份验证。这可以通过 config/kibana.yml 文件中的以下几行来完成：

config/kibana.yml (6.8 and earlier)

elasticsearch.url: "https://localhost:9200" #ensure https not http
xpack.security.enabled: true
elasticsearch.username: "kibana"
elasticsearch.password: "your kibana password goes here"
elasticsearch.ssl.certificateAuthorities: config/certs/client-ca.cer
elasticsearch.ssl.verificationMode: certificate

config/kibana.yml (7.x)

elasticsearch.hosts: "https://localhost:9200"
xpack.security.enabled: true
elasticsearch.username: "kibana_system"
elasticsearch.password: "your kibana password goes here"
elasticsearch.ssl.certificateAuthorities: config/certs/client-ca.cer
elasticsearch.ssl.verificationMode: certificate

请注意：在上面，我们必须使用 https 来进行访问而不是默认的 http。确保我们将 localhost 更改为我们的 Elasticsearch 节点之一的名称，并且证书在 Kibana 文件夹内的 config/certs 目录中可用。

请注意，kibana 用户就像一个服务帐户，它在幕后工作以向 Elasticsearch 集群验证 Kibana 应用程序。我们通常不会以 kibana 用户的身份直接登录 Elasticsearch 集群或 Kibana UI。

重新启动 Kibana 以使其以 kibana 用户身份向 Elasticsearch 集群进行身份验证。我们现在应该能够以 elastic 内置超级用户身份通过 Kibana UI 登录。我们使用 http://localhost:5601 进行登录：

PKI 认证

我们可以使用三个新的客户端证书文件：

$ pwd
/Users/liuxg/elastic0/kibana-7.15.0-darwin-x86_64
$ tree -L 2 config/certs/
config/certs/
├── client-ca.cer
├── client.cer
└── client.key

通过 curl 来测试对集群的 PKI 身份验证。打开一个新终端，cd 到 Kibana 的 config/certs 目录，使用 curl 调用身份验证 API，如下所示。

curl https://localhost:9200/_xpack/security/_authenticate?pretty \\
--key client.key --cert client.cer --cacert client-ca.cer -k -v

请务必将 localhost 替换为我们 Elasticsearch 集群中的节点名称，并确保使用 https（而不是 http）。另请注意，-k 选项是必需的，因为我们没有使用指定的主机名创建证书，因此必须关闭主机名验证。

我们执行上面的指令后，我们在 Elasticsearch 的日志中可以看到如下的信息：

它表明我们当前的 licsens 不支持 pki/pki1。我们需要启动试用功能。我们可以通过如下的命令：

curl -X POST "localhost:9200/_xpack/license/start_trial?acknowledge=true"

或者在 Kibana 的界面中，按照如下的步骤来进去启动：

这样就启动了试用许可的功能。更多关于白金版及黄金版的信息可以在 Elastic 的官方网站 Elasticsearch 官方定价信息：Elastic Cloud、托管型 Elasticsearch | Elastic 找到更多的信息。

启动试用后，重新运行上面的命令：

$ curl https://localhost:9200/_xpack/security/_authenticate?pretty --key client.key --cert client.cer --cacert client-ca.cer -k -v
*   Trying ::1:9200...
* Connected to localhost (::1) port 9200 (#0)
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: client-ca.cer
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Request CERT (13):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS handshake, CERT verify (15):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: CN=instance
*  start date: Sep 30 10:44:43 2021 GMT
*  expire date: Sep 29 10:44:43 2024 GMT
*  issuer: CN=Elastic Certificate Tool Autogenerated CA
*  SSL certificate verify ok.
> GET /_xpack/security/_authenticate?pretty HTTP/1.1
> Host: localhost:9200
> User-Agent: curl/7.71.1
> Accept: */*
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< X-elastic-product: Elasticsearch
< Warning: 299 Elasticsearch-7.15.0-79d65f6e357953a5b3cbcc5e2c7c21073d89aa29 "[GET /_xpack/security/_authenticate] is deprecated! Use [GET /_security/_authenticate] instead."
< content-type: application/json; charset=UTF-8
< content-length: 376
< 
{
  "username" : "something",
  "roles" : [ ],
  "full_name" : null,
  "email" : null,
  "metadata" : {
    "pki_dn" : "CN=something, OU=Consulting Team, DC=mydomain, DC=com"
  },
  "enabled" : true,
  "authentication_realm" : {
    "name" : "pki1",
    "type" : "pki"
  },
  "lookup_realm" : {
    "name" : "pki1",
    "type" : "pki"
  },
  "authentication_type" : "realm"
}
* Connection #0 to host localhost left intact

请注意，roles 值当前为空，这意味着尽管我们已通过 Elasticsearch 的身份验证，但我们无权执行任何操作。身份验证是允许的，因为我们发送到集群的客户端证书是由与 Elasticsearch 节点使用的 http TLS/SSL 证书相同的 CA 签署的。现在我们已经通过身份验证，我们需要授权这个用户能够做一些事情。

从身份验证 API 返回的 pki_dn 值将用于配置将分配给此证书的角色。

打开 Kibana UI，如果我们还没有这样做，请以弹性用户身份登录。由于 elastic 用户具有超级用户权限，因此该用户可以为证书分配角色。从 Kibana 中的 Dev Tools 执行以下命令，确保之前返回的 pki_dn 值复制到 dn 字段中，如下所示：

PUT _xpack/security/role_mapping/kibana_certificate_authorization
{
  "roles": [
    "kibana_system"
  ],
  "rules": {
    "field": {
      "dn": "CN=something, OU=Consulting Team, DC=mydomain, DC=com"
    }
  },
  "enabled": true
}

执行完上面的操作后，我们可以在 Kibana 的界面看到一个额外的信息：

现在我们已经为这个证书分配了 kibana_system 角色，通过另一个对身份验证 API 的调用来验证它的设置是否正确：

curl https://localhost:9200/_xpack/security/_authenticate?pretty \\
--key client.key --cert client.cer --cacert client-ca.cer -k -v

我们应该会看到以下响应，这表明我们现在已将 “kibana_system” 角色分配给此证书。

$ curl https://localhost:9200/_xpack/security/_authenticate?pretty \\
> --key client.key --cert client.cer --cacert client-ca.cer -k -v
*   Trying ::1:9200...
* Connected to localhost (::1) port 9200 (#0)
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: client-ca.cer
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Request CERT (13):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS handshake, CERT verify (15):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: CN=instance
*  start date: Sep 30 10:44:43 2021 GMT
*  expire date: Sep 29 10:44:43 2024 GMT
*  issuer: CN=Elastic Certificate Tool Autogenerated CA
*  SSL certificate verify ok.
> GET /_xpack/security/_authenticate?pretty HTTP/1.1
> Host: localhost:9200
> User-Agent: curl/7.71.1
> Accept: */*
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< X-elastic-product: Elasticsearch
< Warning: 299 Elasticsearch-7.15.0-79d65f6e357953a5b3cbcc5e2c7c21073d89aa29 "[GET /_xpack/security/_authenticate] is deprecated! Use [GET /_security/_authenticate] instead."
< content-type: application/json; charset=UTF-8
< content-length: 398
< 
{
  "username" : "something",
  "roles" : [
    "kibana_system"
  ],
  "full_name" : null,
  "email" : null,
  "metadata" : {
    "pki_dn" : "CN=something, OU=Consulting Team, DC=mydomain, DC=com"
  },
  "enabled" : true,
  "authentication_realm" : {
    "name" : "pki1",
    "type" : "pki"
  },
  "lookup_realm" : {
    "name" : "pki1",
    "type" : "pki"
  },
  "authentication_type" : "realm"
}
* Connection #0 to host localhost left intact

使用 PKI 向 Elasticsearch 集群验证 Kibana

现在我们已经测试了我们的客户端证书并为该证书分配了 “kibana_system” 角色，我们可以使用这个证书而不是用户名和密码来向 Elasticsearch 验证 Kibana。

从我们的 config/kibana.yml 文件中删除以下几行：

6.8 及以前

elasticsearch.username: "kibana"
elasticsearch.password: "XXXXXX"

或者

7.x：

elasticsearch.username: "kibana_system"
elasticsearch.password: "password"

确保将所有相关证书复制到 Kibana 的 config/certs 目录，并将以下几行添加到我们的 kibana.yml 文件中：

7.x

elasticsearch.hosts: "https://localhost:9200"
xpack.security.enabled: true
elasticsearch.ssl.certificate: config/certs/client.cer
elasticsearch.ssl.key: config/certs/client.key
elasticsearch.ssl.certificateAuthorities: config/certs/client-ca.cer
elasticsearch.ssl.verificationMode: certificate

6.8 及以前：

elasticsearch.url: "https://localhost:9200" #ensure https 
xpack.security.enabled: true
elasticsearch.ssl.certificate: config/certs/client.cer
elasticsearch.ssl.key: config/certs/client.key
elasticsearch.ssl.certificateAuthorities: config/certs/client-ca.cer
elasticsearch.ssl.verificationMode: certificate

我们现在可以重新启动 Kibana，它应该对我们的 Elasticsearch 集群进行身份验证，无需任何嵌入的用户名和密码！

结论

在这篇博文中，我演示了如何启用安全性；配置TLS/SSL；为内置用户设置密码；使用PKI进行认证；最后，如何使用 PKI 向 Elasticsearch 集群验证 Kibana。

如果你对 Elasticsearch 的 PKI 身份验证或任何其他与 Elasticsearch 相关的主题有任何疑问，请查看我们的讨论论坛以获得有价值的讨论、见解和信息。

以上是关于Elasticsearch：配置 TLS/SSL 和 PKI 身份验证的主要内容，如果未能解决你的问题，请参考以下文章

用于配置 Azure Function App TLS/SSL“仅 HTTPS”设置的 Az CLI

重识Nginx - 12 SSL/TLS 浅析

邮件TLS/SSL加密通信

FtpWebRequest 使用显式 TLS/SSL

SuperSocket通过证书文件启用 TLS/SSL