Shield with Kibana 3edit

Shield and Kibana 3 have been tested together for recent versions of Chrome, Safari, and IE. This section describes configuration changes and general information to ensure that the two products work together successfully for you.

Kibana 3 uses the kibana-int index to store saved dashboards. All users store dashboards in this index. Enable all users to save and load dashboards from this index. When the Shield plugin is installed, users may be able to load dashboards that access data in indices that they are not authorized to view. A user that loads such a dashboard will receive a Kibana error stating that the disallowed index does not exist.

At the moment, there is no way to control which users can load which dashboards. We expect to address this limitation with future versions of Shield and Kibana.

Kibana configurationedit

Kibana will need to be informed that you wish use credentials. In Kibana’s config.js set the elasticsearch property:

elasticsearch: {server: "http://YOUR_ELASTICSEARCH_SERVER:9200", withCredentials: true}

Elasticsearch configurationedit

HTTP authentication interacts with cross-origin resource sharing (CORS). Clusters that use CORS must send authentication headers to the browser.

In the elasticsearch.yml file on all nodes, add the following configuration entries:

http.cors.enabled: true
http.cors.allow-origin: "https://MYHOST:MYPORT"
http.cors.allow-credentials: true

Note that in http.cors.allow-origin, * is disallowed for credentialed requests. You must enter the correct protocol, hostname and port that would normally be entered into your browser.

Restart the nodes after modifying the configuration file. This change enables Elasticsearch to send the required Access-Control-Allow-Credentials header.

To learn more about enabling CORS, see elasticsearch documentation.

Shield configurationedit

Shield includes a default role for use with Kibana 3:

  cluster: cluster:monitor/nodes/info
    '*': indices:data/read/search, indices:data/read/get, indices:admin/get 
    'kibana-int': indices:data/read/get, indices:data/read/search, indices:data/write/delete, indices:data/write/index,

This line gives the Kibana 3 user read access to indices in order to search and display the data in them. To constrain this role’s access to specific indices, alter the wildcard.

Kibana 3 uses the kibana-int index to save and load dashboards. This role definition allows the user to manage and use the dashboards in the kibana-int index.

Kibana 3 uses the cluster permission to access the /_nodes endpoint in order to check the node version.

Elasticsearch recommends that you create one or more roles derived from this role. These new roles will include access to indices specified by your organization’s goals and policies.

SSL/TLS and browsersedit

Trusting certificatesedit

As discussed in Securing Nodes, Shield supports adding SSL to the Elasticsearch HTTP interface. When using Kibana, your browser verifies that the certificate received from the Elasticsearch node is trusted before sending a request to the node. Establishing this trust requires that either your browser or operating system trust the Certificate Authority (CA) that signed the node’s certificate. To use SSL with Shield and Kibana 3, ensure that the browser or operating system has been configured to trust this CA.

The process to ensure this trust varies per organization. Some organizations will have pre-installed these CA certificates into the operating system or the browser’s local certificate store. If this is the case, you will not need to take any further action.

Other organizations will not have pre-installed the CA certificate. Or you may have created your own CA as discussed in Appendix 1. In these cases, we recommend that you consult your local IT professional to determine the recommended procedure for adding trusted CAs in your organization.

Working with source builds of Kibana 3edit

Some developers use Kibana 3 by pulling the software from our GitHub repository, and not using a built package from our download site. If you do this, be sure to clear your browser’s cache after deploying Shield and configuring the http.cors.allow-credentials parameter to avoid authentication errors with most browsers.