[不错]A step-by-step guide to enabling security, TLS/SSL, and PKI authentication in Elasticsearch
Now posted on the Elastic blog
December 12, 2018 update: This article has been published on Elastic’s website as: https://www.elastic.co/blog/elasticsearch-security-configure-tls-ssl-pki-authentication
Introduction
When Elasticsearch security is enabled for a cluster that is running with a production license, the use of TLS/SSL for transport communications is obligatory and must be correctly setup. Additionally, once security has been enabled, all communications to an Elasticsearch cluster must be authenticated, including communications from Kibana and/or application servers.
The simplest way that Kibana and/or application servers can authenticate to an Elasticsearch cluster is by embedding a username and password in their configuration files or source code. However, in many organizations, it is forbidden to store usernames and passwords in such locations. In this case, one alternative is to use Public Key Infrastructure (PKI) (client certificates) for authenticating to an Elasticsearch cluster.
Configuring security along with TLS/SSL and PKI can seem daunting at first, and so this blog gives step-by-step instructions on how to: enable security; configure TLS/SSL; set passwords for built-in users; use PKI for authentication; and finally, how to authenticate Kibana to an Elasticsearch cluster using PKI.
Enabling security
In order to enable security it is necessary to have either a Gold or Platinum subscription, or a trial license enabled via Kibana or API. For example, the following command would enable a trial license via the API:
curl -X POST "localhost:9200/_xpack/license/start_trial?acknowledge=true"
Where localhost
must be replaced with the name of a node in our Elasticsearch cluster.
After enabling a license, security can be enabled. We must modify the elasticsearch.yml
file on each node in the cluster with the following line:
xpack.security.enabled: true
For a cluster that is running in production mode with a production license, once security is enabled, transport TLS/SSL must also be enabled. However, if we are running with a trial license, then transport TLS/SSL is not obligatory.
If we are running with a production license and we attempt to start the cluster with security enabled before we have enabled transport TLS/SSL, we will see the following error message:
Transport SSL must be enabled for setups with production licenses. Please set [xpack.security.transport.ssl.enabled] to [true] or disable security by setting [xpack.security.enabled] to [false]
Configuration of TLS/SSL is covered in the following sections.
TLS/SSL encryption
Elasticsearch has two levels of communications, transport communications and http communications. The transport protocol is used for internal communications between Elasticsearch nodes, and the http protocol is used for communications from clients to the Elasticsearch cluster. Securing these communications will be discussed in the following paragraphs.
Transport TLS/SSL encryption
The transport protocol is used for communication between nodes within an Elasticsearch cluster. Because each node in an Elasticsearch cluster is both a client and a server to other nodes in the cluster, all transport certificates must be both client and server certificates. If TLS/SSL certificates do not have Extended Key Usage
defined, then they are already defacto client and server certificates. If transport certificates do have an Extended Key Usage
section, which is usually the case for CA-signed certificates used in corporate environments, then they must explicitly enable both clientAuth and serverAuth.
Note that Elasticsearch comes with a utility called elasticsearch-certutilthat can be used for generating self-signed certificates that can be used for encrypting internal communications within an Elasticsearch cluster.
The following commands can be used for generating certificates that can be used for transport communications, as described in this page on Encrypting Communications in Elasticsearch:
bin/elasticsearch-certutil ca
ENTER ENTER
bin/elasticsearch-certutil cert --ca elastic-stack-ca.p12
ENTER ENTER ENTER
Once the above commands have been executed, we will have TLS/ SSL certificates that can be used for encrypting communications.
The newly created certificates should be copied into a sub-directory called certs
located within the config
directory. The certificates will then be specified in the elasticsearch.yml
file as follows:
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
Now restart all of the nodes in our Elasticsearch cluster for the above changes to take effect.
Define built-in user’s passwords
We must now define passwords for the built-in users as described in Setting built-in user passwords. Note that if we are running with a Gold or Platinum license, the previous steps to enable TLS/SSL for the transport communications must be executed before the cluster will start. Additionally, note that setting built-in user’s passwords should be completed before we enable TLS/SSL for http communications, as the command for setting passwords will communicate with the cluster via unsecured http.
Built-in users passwords can be setup with the following command:
bin/elasticsearch-setup-passwords interactive
Be sure to remember the passwords that we have assigned for each of the built-in users. We will make use of the elastic
superuser to help configure PKI authentication later in this blog.
Http TLS/SSL encryption
For http communications, the Elasticsearch nodes will only act as servers and therefore can use Server certificates — i.e. http TLS/SSL certificates do not need to enable Client authentication.
In many cases, certificates for http communications would be signed by a corporate CA. It is worth noting that the certificates used for encrypting http communications can be totally independent from the certificates that are used for transport communications.
To reduce the number of steps in this blog, we’ll use the same certificates for http communications as we have already used for the transport communications. These are specified in elasticsearch.yml
file as follows:
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
Enabling PKI authentication
As discussed inConfiguring a PKI Realm, the following must be added to the elasticsearch.yml
file to allow PKI authentication.
xpack.security.authc.realms.pki1.type: pki
Combined changes to elasticsearch.yml
Once the above steps have been followed, we should have the following defined in our elasticsearch.yml configuration:
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.pki1.type: pki
Note that once the above changes have been made to our elasticsearch.yml
file, we will have to restart all of the Elasticsearch nodes in our cluster in order for the changes to take effect.
Creating a client certificate
Certificates that will be used for PKI authentication must be signed by the same CA as the certificates that are used for encrypting http communications. Normally, these would be signed by an official CA within an organization. However, because we have already used a self signed CA, we also sign our http client certificates with that same self-signed CA which we previously saved as elastic-stack-ca.p12
. We can create a certificate for client authentication as follows:
bin/elasticsearch-certutil cert --ca \
config/certs/elastic-stack-ca.p12 \
-name "CN=something,OU=Consulting Team,DC=mydomain,DC=com"
ENTER
client.p12 ENTER
ENTER
The above will create a file called client.p12
, which contains all of the information required for PKI authentication to our Elasticsearch cluster. However, in order to use this certificate it is helpful to break it into its private key, public certificate, and CA certificate. This can be done with the following commands:
Private Key
openssl pkcs12 -in client.p12 -nocerts -nodes > client.key
Public Certificate
openssl pkcs12 -in client.p12 -clcerts -nokeys > client.cer
CA Certificate
openssl pkcs12 -in client.p12 -cacerts -nokeys -chain > client-ca.cer
Which should produce three files,
client.key
— The private keyclient.cer
— The public certificateclient-ca.cer
— The CA that signed the public certificate
Create a directory called certs in Kibana’s config directory, and move all of the client certificates there.
Configure Kibana to authenticate to elasticsearch
Now that we have enabled security on the Elasticsearch cluster, communications to the cluster must be authenticated. Therefore, if we plan on using Kibana to interact with the cluster, then we must enable security and configure Kibana to authenticate to the cluster as the kibana
user over https. As we have not yet fully setup PKI authentication from Kibana to the Elasticsearch cluster, authentication can initially be done with the following lines in the kibana.yml
file:
elasticsearch.url: "https://localhost:9200" #ensure https not http
xpack.security.enabled: true
elasticsearch.username: "kibana"
elasticsearch.password: "our new kibana password here"
elasticsearch.ssl.certificateAuthorities: config/certs/client-ca.cer
elasticsearch.ssl.verificationMode: certificate
Ensure that we change localhost
to the name of one of our Elasticsearch nodes, and that the certificates are available in the config/certs directory within the Kibana folder.
Note that the kibana
user is like a service account that works behind the scenes to authenticate the Kibana application to the Elasticsearch cluster. We will generally never directly login to the Elasticsearch cluster or into the Kibana UI as the kibana
user.
Restart Kibana in order for it to authenticate to the Elasticsearch cluster as the kibana
user. We should be able to now login through the Kibana UI as the elastic
built-in superuser.
PKI Authentication
We can use the three new client certificate files to test PKI authentication to the cluster with curl. Open a new terminal and cd to Kibana’s config/certs directory, and use curl to call the authenticate API as shown below.
curl https://localhost:9200/_xpack/security/_authenticate?pretty \
--key client.key --cert client.cer --cacert client-ca.cer -k -v
Be sure to replace localhost
with the name of a node in our Elasticsearch cluster and be sure to use https (not http). Also note that the -k option is required as we did not create certificates with the hostnames specified, and therefore hostname verification must be turned off.
The above command should respond with something similar to the following:
{
"username" : "something",
"roles" : [ ],
"full_name" : null,
"email" : null,
"metadata" : {
"pki_dn" : "CN=something, OU=Consulting Team, DC=mydomain, DC=com"
},
"enabled" : true
}
Notice that the roles is currently empty which means that although we have authenticated to Elasticsearch, we are not authorized to perform any actions. Authentication is allowed because the client certificate that we sent to the cluster was signed by the same CA as the http TLS/SSL certificates used by the Elasticsearch nodes. Now that we are authenticated, we need to authorize this user to be able to do something.
The pki_dn value returned from the authenticate API will be used to configure the roles that will be assigned to this certificate.
Open the Kibana UI and if we have not already done so, login as the elastic
user. As the elastic
user has superuser privileges, this user can assign roles to the certificate. Execute the following command from Dev Tools in Kibana, ensuring that the previously returned pki_dn
value is copied into the dn
field as follows:
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
}
Now that we have assigned kibana_system
role to this certificate, verify this is set correctly with another call to the authenticate API:
curl https://localhost:9200/_xpack/security/_authenticate?pretty \
--key client.key --cert client.cer --cacert client-ca.cer -k -v
And we should see the following response, which indicates that we now have the “kibana_system” role assigned to this certificate.
{
"username" : "something",
"roles" : [
"kibana_system" ],
"full_name" : null,
"email" : null,
"metadata" : {
"pki_dn" : "CN=something, OU=Consulting Team, DC=mydomain, DC=com"
},
"enabled" : true
}
Using PKI to authenticate Kibana to the Elasticsearch cluster
Now that we have tested our client-side certificate and assigned the kibana_system
role to the certificate, we can use this certificate instead of a username and password, to authenticate Kibana to Elasticsearch.
Remove the following lines from our kibana.yml
file:
elasticsearch.username: "kibana"
elasticsearch.password: "XXXXXX"
Ensure that all relevant certificates are copied to Kibana’s config/certs directory, and add the following lines to our kibana.yml
file:
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
We can now restart Kibana, and it should authenticate to our Elasticsearch cluster, without any need for an embedded username and password!
Conclusion
In this blog post, I have demonstrated how to: enable security; configure TLS/SSL; set passwords for built-in users; use PKI for authentication; and finally, how to authenticate Kibana to an Elasticsearch cluster using PKI.
If you have any questions about PKI authentication with Elasticsearch, or any other Elasticsearch-related topics, have a look at our Discuss forumsfor valuable discussion, insights, and information.
[不错]A step-by-step guide to enabling security, TLS/SSL, and PKI authentication in Elasticsearch的更多相关文章
- Tomcat Clustering - A Step By Step Guide --转载
Tomcat Clustering - A Step By Step Guide Apache Tomcat is a great performer on its own, but if you'r ...
- Step by step guide to set up master and slave machines(转)
Note: There is no need to install Jenkins on the slave machine. On your master machine go to Manage ...
- Step by step guide to set up master and slave machines on Windows
Note: There is no need to install Jenkins on the slave machine. On your master machine go to Manage ...
- Step by Step use OBD2 Scanner Guide
Learning to use a good automotive OBD2 code reader is one of the best ways you can continually inves ...
- Step by step Dynamics CRM 2011升级到Dynamics CRM 2013
原创地址:http://www.cnblogs.com/jfzhu/p/4018153.html 转载请注明出处 (一)检查Customizations 从2011升级到2013有一些legacy f ...
- WPF Step By Step 自定义模板
WPF Step By Step 自定义模板 回顾 上一篇,我们简单介绍了几个基本的控件,本节我们将讲解每个控件的样式的自定义和数据模板的自定义,我们会结合项目中的具体的要求和场景来分析,给出我们实现 ...
- e2e 自动化集成测试 架构 实例 WebStorm Node.js Mocha WebDriverIO Selenium Step by step (四) Q 反回调
上一篇文章“e2e 自动化集成测试 架构 京东 商品搜索 实例 WebStorm Node.js Mocha WebDriverIO Selenium Step by step (三) SqlServ ...
- e2e 自动化集成测试 架构 实例 WebStorm Node.js Mocha WebDriverIO Selenium Step by step (二) 图片验证码的识别
上一篇文章讲了“e2e 自动化集成测试 架构 京东 商品搜索 实例 WebStorm Node.js Mocha WebDriverIO Selenium Step by step 一 京东 商品搜索 ...
- enode框架step by step之Staged event-driven architecture思想的运用
enode框架step by step之Staged event-driven architecture思想的运用 enode框架系列step by step文章系列索引: 分享一个基于DDD以及事件 ...
随机推荐
- 清北学堂dp图论营游记day3
.状态压缩dp: 对于这个我们引入二进制状态压缩,因为任何一个数都可以二进制表示,而其二进制表示上每一位都可以表示当前位置是否有元素,这就构成了状态压缩. 对于这个题,上下行&一下就行. 状压 ...
- Kendo UI for jQuery使用教程:操作系统/jQuery支持等
[Kendo UI for jQuery最新试用版下载] Kendo UI目前最新提供Kendo UI for jQuery.Kendo UI for Angular.Kendo UI Support ...
- Nginx 0.8.x + PHP 5.2.13(FastCGI)搭建胜过Apache十倍的Web服务器
[文章作者:张宴 本文版本:v6.3 最后修改:2010.07.26 转载请注明原文链接:http://blog.zyan.cc/nginx_php_v6/] 前言:本文是我撰写的关于搭建“Nginx ...
- php上传文件代码解析
思想:把html的input标签组织成一个数组,然后去重 关键技术涉及的函数 is_dir mkdir move_uploaded_file() 涉及的数组 预定义数组$_FILES 步骤一:检查上传 ...
- 【MongoDB系列】简介、安装、基本操作命令
文章内容概述: 1.MongoDB介绍 2.MongoDB安装(windows及Linux) 3.MongoDB基本操作命令 MongoDB介绍: MongoDB 是一个基于分布式文件存储的数据库.由 ...
- 2019春Python程序设计测试(20190604--20190604)
1-1 在Python 3.x中可以使用中文作为变量名. (2分) T F 1-2 Python变量使用前必须先声明,并且一旦声明就不能再当前作用域内改变其类型.(2分) T ...
- 1、布局容器Grid、StackPanel、GroupBox、DockPanel、WrapPanel
Grid——网格布局,其中控件或容器需指定位置 StackPanel——堆叠面板,其中的控件水平布局.竖直布局 DockPanel——停靠面板,内部控件或容器可以放置在上.下.左.右 WrapPane ...
- Vue.js——vue-resource详细介绍
概述 Vue.js是数据驱动的,这使得我们并不需要直接操作DOM,如果我们不需要使用jQuery的DOM选择器,就没有必要引入jQuery.vue-resource是Vue.js的一款插件,它可以通过 ...
- Andorid获取状态栏高度
在应用开发中,有时我们需要用代码计算布局的高度,可能需要减去状态栏(status bar)的高度.状态栏高度定义在Android系统尺寸资源中status_bar_height,但这并不是公开可直接使 ...
- JIRA7.13版本创建项目:工作流(二)
工作流 在上一篇文章中,我们新建了一个问题类型,并且增加到问题类型方案里了,同时又关联到我们的这个项目中.那么这些问题我们需要如何设置流程走向来表示问题的处理过程呢?这就需要设定一个流程,并将这个流程 ...