Added step-by-step instructions for using Kibana with Shield. Closes elastic/elasticsearch#283.
Original commit: elastic/x-pack-elasticsearch@f3aab8e6a4
This commit is contained in:
debadair
parent
101ea6deab
commit
25d7dfa555
|
|
@ -2,144 +2,299 @@
|
|||
[[kibana]]
|
||||
=== Using Kibana with Shield
|
||||
|
||||
Shield supports both Kibana 3 and Kibana 4.0+ releases. The configuration required differs
|
||||
between Kibana 3 and 4. Please follow the instructions below for the version of Kibana you are working with.
|
||||
Shield supports both Kibana 3 and Kibana 4.0 and later. To set things up, you need to update your Kibana configuration and define and assign roles for your Kibana users in Shield. If you're using Kibana 3, you also need to enable cross-origin resource sharing (CORS) in Elasticsearch.
|
||||
If you're using Kibana 4, you need to configure credentials for the Kibana server. The following sections provide step-by-step instructions for using <<using-kibana3-with-shield,Kibana 3>> and <<using-kibana4-with-shield,Kibana 4>> with Shield.
|
||||
|
||||
NOTE: With Shield installed, if you load a Kibana dashboard that accesses data in an index that you are not authorized to view, you get an error that indicates the index does not exist. Kibana and Shield do not currently provide a way to control which users can load which dashboards.
|
||||
|
||||
[[using-kibana3-with-shield]]
|
||||
[float]
|
||||
==== Using Kibana 3 with Shield
|
||||
|
||||
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 users have to authenticate when your cluster has Shield installed. You configure Shield roles for your Kibana users to control what data those users can access. In addition, you can encrypt communications between the browser and Elasticsearch.
|
||||
|
||||
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.
|
||||
|
||||
[float]
|
||||
===== Configuring Kibana 3
|
||||
Kibana will need to be informed that you wish use credentials. In Kibana's `config.js` set the `elasticsearch` property:
|
||||
[[cors]]
|
||||
To use Kibana 3 with Shield:
|
||||
|
||||
. Configure Kibana to use credentials when communicating with Elasticsearch. To do this, set `withCredentials` to `true` in the `elasticsearch` property in Kibana's `config.js` file:
|
||||
+
|
||||
[source,yaml]
|
||||
------------------------------------
|
||||
elasticsearch: {server: "http://YOUR_ELASTICSEARCH_SERVER:9200", withCredentials: true}
|
||||
------------------------------------
|
||||
+
|
||||
IMPORTANT: If SSL encryption is enabled in Shield, specify the HTTPS protocol in the Elasticsearch URL rather than HTTP.
|
||||
|
||||
[float]
|
||||
[[cors]]
|
||||
===== Enabling CORS in Elasticsearch
|
||||
|
||||
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:
|
||||
|
||||
. Enable CORS in Elasticsearch and allow credentialed requests. To do this, set the following properties in `elasticsearch.yml` on each node in your cluster and restart the nodes:
|
||||
+
|
||||
[source,yaml]
|
||||
------------------------------------
|
||||
http.cors.enabled: true
|
||||
http.cors.allow-origin: "https://MYHOST:MYPORT"
|
||||
http.cors.allow-credentials: true
|
||||
http.cors.enabled: true <1>
|
||||
http.cors.allow-origin: "https://MYHOST:MYPORT" <2>
|
||||
http.cors.allow-credentials: true <3>
|
||||
------------------------------------
|
||||
<1> Enables CORS. For more information, see http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/modules-http.html[HTTP] in the Elasticsearch Reference.
|
||||
<2> Specifies the webserver you are using for Kibana. Note that you must explicitly specify your server's protocol, hostname, and port--you cannot simply specify a wildcard `*` when using credentialed requests.
|
||||
<3> Sends authentication headers to the browser.
|
||||
+
|
||||
NOTE: If you are using a source build of Kibana 3, you might encounter authentication errors when trying to connect to Kibana 3 after deploying Shield and configuring the `http.cors.allow-credentials` property. If you do, simply clear your browser's cache and reconnect.
|
||||
|
||||
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.
|
||||
|
||||
NOTE: To learn more about enabling CORS, see http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/modules-http.html[Elasticsearch Reference].
|
||||
|
||||
[float]
|
||||
===== Configuring Shield for Kibana 3
|
||||
|
||||
Shield includes a default <<roles,role>> for use with Kibana 3:
|
||||
|
||||
. Derive Kibana 3 user roles from the default <<kibana3-user-role, `kibana3` user role>> and add them to `roles.yml` to control which indices your Kibana users can access. Kibana users need access to the indices that they will be working with and the `kibana-int` index where their dashboards are stored. The default `kibana3` role grants read access to all indices and full access to the `kibana-int` index.
|
||||
+
|
||||
IMPORTANT: We strongly recommend creating custom `kibana3` user roles
|
||||
to limit access to specific indices according to your organization's goals and policies. You can define as many different roles for your Kibana users as you need.
|
||||
+
|
||||
To constrain Kibana's access to specific indices, explicitly specify the index names in your role. When configuring a role for a Kibana user and granting access to a specific index, at a minimum the user needs the following privileges on the index:
|
||||
+
|
||||
--------------------------------------------------------------------------------
|
||||
indices:admin/mappings/fields/get
|
||||
indices:admin/validate/query
|
||||
indices:data/read/search
|
||||
indices:data/read/msearch
|
||||
indices:admin/get
|
||||
--------------------------------------------------------------------------------
|
||||
+
|
||||
For example, the following `kibana3_monitoring` role only allows users to build dashboards using data in the `logstash-*` indices.
|
||||
+
|
||||
[source,yaml]
|
||||
------------------------------------------------------------------------------------------------------------------------
|
||||
kibana3:
|
||||
cluster: cluster:monitor/nodes/info
|
||||
--------------------------------------------------------------------------------
|
||||
kibana3_monitoring:
|
||||
cluster:
|
||||
- cluster:monitor/nodes/info <1>
|
||||
indices:
|
||||
'*': indices:data/read/search, indices:data/read/get, indices:admin/get <1>
|
||||
'kibana-int': indices:data/read/get, indices:data/read/search, indices:data/write/delete, indices:data/write/index,
|
||||
create_index
|
||||
------------------------------------------------------------------------------------------------------------------------
|
||||
'logstash-*':
|
||||
- indices:admin/mappings/fields/get
|
||||
- indices:admin/validate/query
|
||||
- indices:data/read/search
|
||||
- indices:data/read/msearch
|
||||
- indices:admin/get
|
||||
'.kibana-int': <2>
|
||||
- indices:data/read/get
|
||||
- indices:data/read/search
|
||||
- indices:data/write/delete
|
||||
- indices:data/write/index
|
||||
- create_index
|
||||
--------------------------------------------------------------------------------
|
||||
<1> Kibana 3 uses the cluster permission to access the `/_nodes` endpoint to check the node version.
|
||||
<2> All Kibana users need access to the `kibana-int` index.
|
||||
|
||||
<1> 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.
|
||||
. Assign the appropriate roles to your Kibana users or groups of users:
|
||||
|
||||
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 browsers
|
||||
|
||||
===== Trusting certificates
|
||||
As discussed in <<securing-communications, Securing Communications>>, 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.
|
||||
|
||||
[float]
|
||||
===== Configuring Your Browser to Use SSL
|
||||
As discussed in <<securing-communications, Securing Communications with Encryption and IP Filtering>>, 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 <<certificate-authority, Setting Up a Certificate Authority>>. In these cases, we recommend that you consult your local IT professional to
|
||||
determine the recommended procedure for adding trusted CAs in your organization.
|
||||
|
||||
[float]
|
||||
===== Working with source builds of Kibana 3
|
||||
|
||||
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.
|
||||
|
||||
[float]
|
||||
==== Using Kibana 4 with Shield
|
||||
|
||||
Kibana 4 adds a server-side component that changes the integration with Shield and the steps required to configure Shield, Elasticsearch, and Kibana to work together. With Kibana 4, the browser makes requests to the Kibana 4 server, and not to Elasticsearch directly. The Kibana 4 server then makes requests to Elasticsearch on behalf of the browser. We recommend using separate roles for your users who log into Kibana and for the Kibana 4 server itself.
|
||||
|
||||
[float]
|
||||
[[kibana4-roles]]
|
||||
===== Configuring Roles for Kibana 4 Users
|
||||
|
||||
Kibana users need access to the indices that they will be working with and the `.kibana` index where their
|
||||
saved searches, visualizations, and dashboards are stored. Shield includes a default `kibana4` role that grants
|
||||
read access to all indices and full access to the `.kibana` index.
|
||||
|
||||
IMPORTANT: The default Kibana 4 user role grants read access to all indices. We strongly recommend deriving
|
||||
custom roles for your Kibana users that limit access to specific indices according to your organization's goals and policies.
|
||||
** If you're using the default `esusers` realm, you can assign roles when you <<esusers-add, add a user>>, or modify the role assignments with the <<esusers-roles, `roles`>> command. For example, the following command creates a user named `jacknich` and assigns the `kibana3_monitoring` role:
|
||||
+
|
||||
[source,console]
|
||||
--------------------------------------------------------------------------------
|
||||
esusers useradd jacknich -r kibana3_monitoring -p password
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
** If you are using an LDAP or Active Directory realm, you can either assign roles on a per user basis, or assign roles to groups of users. By default, role mappings are stored in <<mapping-roles, `config/shield/role_mapping.yml`>>. For example, the following snippet assigns the `kibana3_monitoring` role to the group named `admins` and the user named Jack Nicholson:
|
||||
+
|
||||
[source,yaml]
|
||||
------------------------------------------------------------------------------------------------------------------------
|
||||
kibana4:
|
||||
--------------------------------------------------------------------------------
|
||||
kibana3_monitoring:
|
||||
- "cn=admins,dc=example,dc=com"
|
||||
- "cn=Jack Nicholson,dc=example,dc=com"
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
** If you are using a PKI realm, you assign roles on a per user basis in the role mapping file.
|
||||
For example, the following snippet assigns the `kibana3_monitoring` role to the users named `Jack Nicholson` and `Robert De Niro.
|
||||
+
|
||||
[source,yaml]
|
||||
--------------------------------------------------------------------------------
|
||||
kibana3_monitoring:
|
||||
- "cn=Jack Nicholson,ou=example,o=com"
|
||||
- "cn=Robert De Niro,ou=example,o=com"
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
. If you have <<ssl-tls, enabled SSL encryption>> in Shield and are using your own Certificate Authority (CA) to sign certificates for your nodes, configure your browser or operating system to trust your CA. When you access 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 CA that signed the node's certificate. Consult your local IT professional for information about the recommended procedure for adding trusted CAs in your organization.
|
||||
|
||||
. Access Kibana 3 from your browser and verify that you can sign in as a user. For example, you could log in as the `jacknich` user created in step 4.
|
||||
|
||||
[float]
|
||||
[[using-kibana4-with-shield]]
|
||||
==== Using Kibana 4 with Shield
|
||||
Kibana users have to authenticate when your cluster has Shield installed. You configure Shield roles for your Kibana users to control what data those users can access. Kibana 4 runs a webserver that makes requests to Elasticsearch on the client's behalf, so you also need to configure credentials for the Kibana server so those requests can be authenticated. In addition, you can encrypt communications between the Kibana server and Elasticsearch.
|
||||
|
||||
To use Kibana 4 with Shield:
|
||||
|
||||
. Configure credentials for the Kibana server. The Kibana server needs access to the cluster monitoring APIs and the `.kibana` index. The server does _not_ need access to user indexes. The required privileges are specified in the <<kibana4-server-role, kibana4_server role>> provided in the default Shield <<defining-roles,`roles.yml`>> file.
|
||||
|
||||
.. Create a user account for the Kibana server and assign it the `kibana4_server` role. For example, if you're using the default `esusers` realm, you can create a `kibana-server` user with the <<esusers-add, `useradd`>> command:
|
||||
+
|
||||
[source,console]
|
||||
--------------------------------------------------------------------------------
|
||||
esusers useradd kibana4-server -r kibana4_server -p password
|
||||
--------------------------------------------------------------------------------
|
||||
+
|
||||
If you are using an LDAP, Active Directory, or PKI realm, you need to create a user for the
|
||||
Kibana server and map the user's distinguished name to the `kibana4_server` role in the Shield <<mapping-roles, role mapping>> file. By default, role mappings are stored in `config/shield/role_mapping.yml`. For example, the following snippet assigns the `kibana4_server` role to an LDAP or Active Directory user named `kibana-server`:
|
||||
+
|
||||
[source,yaml]
|
||||
--------------------------------------------------------------------------------
|
||||
kibana4_server:
|
||||
- "cn=kibana-server,cn=applications,dc=example,dc=com"
|
||||
--------------------------------------------------------------------------------
|
||||
+
|
||||
For PKI realms, you specify the user's common name, organizational unit, and organization:
|
||||
+
|
||||
[source,yaml]
|
||||
--------------------------------------------------------------------------------
|
||||
kibana4_server:
|
||||
- "cn=kibana-server,ou=example,o=com"
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
.. Specify the credentials for your Kibana server user in the Kibana configuration
|
||||
file, `/config/kibana.yml`.
|
||||
+
|
||||
[source,yaml]
|
||||
--------------------------------------------------------------------------------
|
||||
kibana_elasticsearch_username: kibana4-server
|
||||
kibana_elasticsearch_password: password
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
[[kibana4-roles]]
|
||||
. Derive Kibana 4 user roles from the default <<kibana4-user-role, `kibana4` user role>> and add them to `roles.yml` to control which indices your Kibana users can access. Kibana users need access to the indices that they will be working with and the `.kibana` index where their saved searches, visualizations, and dashboards are stored. The default `kibana4` role grants read access to all indices and full access to the `.kibana` index.
|
||||
+
|
||||
IMPORTANT: We strongly recommend creating custom `kibana4` user roles
|
||||
to limit access to specific indices according to your organization's goals and policies. You can define as many different roles for your Kibana 4 users as you need.
|
||||
+
|
||||
To constrain Kibana's access to specific indices, explicitly specify the index names in your role. When configuring a role for a Kibana user and granting access to a specific index, at a minimum the user needs the following privileges on the index:
|
||||
+
|
||||
--------------------------------------------------------------------------------
|
||||
indices:admin/mappings/fields/get
|
||||
indices:admin/validate/query
|
||||
indices:data/read/search
|
||||
indices:data/read/msearch
|
||||
indices:admin/get
|
||||
--------------------------------------------------------------------------------
|
||||
+
|
||||
For example, the following `kibana4_monitoring` role only allows users to discover and visualize data in the `logstash-*` indices.
|
||||
+
|
||||
[source,yaml]
|
||||
--------------------------------------------------------------------------------
|
||||
kibana4_monitoring:
|
||||
cluster:
|
||||
- cluster:monitor/nodes/info
|
||||
- cluster:monitor/health
|
||||
indices:
|
||||
'logstash-*':
|
||||
- indices:admin/mappings/fields/get
|
||||
- indices:admin/validate/query
|
||||
- indices:data/read/search
|
||||
- indices:data/read/msearch
|
||||
- indices:admin/get
|
||||
'.kibana': <1>
|
||||
- indices:admin/create
|
||||
- indices:admin/exists
|
||||
- indices:admin/mapping/put
|
||||
- indices:admin/mappings/fields/get
|
||||
- indices:admin/refresh
|
||||
- indices:admin/validate/query
|
||||
- indices:data/read/get
|
||||
- indices:data/read/mget
|
||||
- indices:data/read/search
|
||||
- indices:data/write/delete
|
||||
- indices:data/write/index
|
||||
- indices:data/write/update
|
||||
--------------------------------------------------------------------------------
|
||||
<1> All Kibana users need access to the `.kibana` index.
|
||||
|
||||
. Assign the appropriate roles to your Kibana users or groups of users:
|
||||
|
||||
** If you're using the default `esusers` realm, you can assign roles when you <<esusers-add, add a user>>, or modify the role assignments with the <<esusers-roles, `roles`>> command. For example, the following command creates a user named `jacknich` and assigns the `kibana4_monitoring` role:
|
||||
+
|
||||
[source,console]
|
||||
--------------------------------------------------------------------------------
|
||||
esusers useradd jacknich -r kibana4_monitoring -p password
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
** If you are using an LDAP or Active Directory realm, you can either assign roles on a per user basis, or assign roles to groups of users. By default, role mappings are stored in <<mapping-roles, `config/shield/role_mapping.yml`>>. For example, the following snippet assigns the `kibana4_monitoring` role to the group named `admins` and the user named Jack Nicholson:
|
||||
+
|
||||
[source,yaml]
|
||||
--------------------------------------------------------------------------------
|
||||
kibana4_monitoring:
|
||||
- "cn=admins,dc=example,dc=com"
|
||||
- "cn=Jack Nicholson,dc=example,dc=com"
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
** If you are using a PKI realm, you assign roles on a per user basis in the role mapping file.
|
||||
For example, the following snippet assigns the `kibana4_monitoring` role to the users named `Jack Nicholson` and `Robert De Niro`.
|
||||
+
|
||||
[source,yaml]
|
||||
--------------------------------------------------------------------------------
|
||||
kibana4_monitoring:
|
||||
- "cn=Jack Nicholson,ou=example,o=com"
|
||||
- "cn=Robert De Niro,ou=example,o=com"
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
. If you have enabled SSL encryption in Shield, configure Kibana 4 to connect to Elasticsearch via HTTPS. To do this:
|
||||
|
||||
.. Specify the HTTPS protocol in the `elasticsearch` URL setting in the Kibana configuration file, `kibana.yml`:
|
||||
+
|
||||
[source,yaml]
|
||||
--------------------------------------------------------------------------------
|
||||
elasticsearch: "https://<your_elasticsearch_host>.com:9200"
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
.. If you are using your own CA to sign certificates for Elasticsearch, set the `ca` property in `kibana.yml` to specify the location of the PEM file.
|
||||
+
|
||||
[source,yaml]
|
||||
--------------------------------------------------------------------------------
|
||||
ca: /path/to/your/ca/cacert.pem
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
. Configure Kibana 4 to encrypt communications between the browser and the Kibana server. To do this, configure the `ssl_key_file` and `ssl_cert_file` properties in `kibana.yml` and restart Kibana:
|
||||
+
|
||||
[source,yaml]
|
||||
--------------------------------------------------------------------------------
|
||||
ssl_key_file: /path/to/your/server.key
|
||||
ssl_cert_file: /path/to/your/server.crt
|
||||
--------------------------------------------------------------------------------
|
||||
+
|
||||
Once you enable SSL encryption between the browser and the Kibana server, access Kibana via HTTPS. For example, `https://localhost:5601`.
|
||||
+
|
||||
NOTE: Enabling browser encryption is required to prevent passing user credentials in the clear in Kibana 4.0 and 4.1.
|
||||
|
||||
. Restart Kibana and verify that you can sign in as a user. If you are running Kibana locally,
|
||||
go to `localhost:5601` and enter the credentials for a user you've assigned a Kibana user role. For example, you could log in as the `jacknich` user created in step 3.
|
||||
+
|
||||
NOTE: Sign in as a Kibana user--the Kibana server credentials should only be used internally by the Kibana server. The `kibana4_server` role doesn't grant permission to create the `.kibana` index or access user indices.
|
||||
|
||||
[float]
|
||||
[[default-roles]]
|
||||
==== Default Roles for Kibana
|
||||
|
||||
Default roles for Kibana 3 and Kibana 4 are provided in `roles.yml`.
|
||||
|
||||
IMPORTANT: The default user roles grant read access to all indices. We strongly recommend deriving custom roles for your Kibana users that limit access to specific indices according to your organization's goals and policies.
|
||||
|
||||
[[kibana3-user-role]]
|
||||
.Kibana 3 User Role
|
||||
[source,yaml]
|
||||
--------------------------------------------------------------------------------
|
||||
kibana3:
|
||||
cluster: cluster:monitor/nodes/info
|
||||
indices:
|
||||
'*': indices:data/read/search, indices:data/read/get, indices:admin/get
|
||||
'kibana-int': indices:data/read/search, indices:data/read/get, indices:data/write/delete, indices:data/write/index, create_index
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
[[kibana4-user-role]]
|
||||
.Kibana 4 User Role
|
||||
[source,yaml]
|
||||
--------------------------------------------------------------------------------
|
||||
kibana4:
|
||||
cluster:
|
||||
- cluster:monitor/nodes/info
|
||||
- cluster:monitor/health
|
||||
indices:
|
||||
'*':
|
||||
- indices:admin/mappings/fields/get
|
||||
- indices:admin/validate/query
|
||||
- indices:data/read/search
|
||||
- indices:data/read/msearch
|
||||
- indices:admin/get
|
||||
'.kibana':
|
||||
- indices:admin/create
|
||||
- indices:admin/exists
|
||||
- indices:admin/mapping/put
|
||||
- indices:admin/mappings/fields/get
|
||||
|
|
@ -152,35 +307,20 @@ kibana4:
|
|||
- indices:data/write/index
|
||||
- indices:data/write/update
|
||||
- indices:admin/create
|
||||
------------------------------------------------------------------------------------------------------------------------
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
To constrain Kibana's access to specific indices, explicitly specify the index names in your role. When configuring a role for a Kibana user and granting access to a specific index, at a minimum the user needs the following privileges on the index:
|
||||
|
||||
* `indices:admin/mappings/fields/get`
|
||||
* `indices:admin/validate/query`
|
||||
* `indices:data/read/search`
|
||||
* `indices:data/read/msearch`
|
||||
* `indices:admin/get`
|
||||
|
||||
[float]
|
||||
[[kibana4-server-role]]
|
||||
===== Configuring a Role for the Kibana 4 Server
|
||||
|
||||
The Kibana 4 server needs access to the cluster monitoring APIs and the `.kibana` index. However, the server
|
||||
does not need access to user indexes. The following `kibana4_server` role shows the privileges required
|
||||
by the Kibana 4 server.
|
||||
|
||||
NOTE: This role is included in roles.yml by default as of Shield 1.1. If you are running an older version of Shield,
|
||||
you need to add it yourself.
|
||||
|
||||
.Kibana 4 Server Role
|
||||
[source,yaml]
|
||||
------------------------------------------------------------------------------------------------------------------------
|
||||
--------------------------------------------------------------------------------
|
||||
kibana4_server:
|
||||
cluster:
|
||||
- cluster:monitor/nodes/info
|
||||
- cluster:monitor/health
|
||||
indices:
|
||||
'.kibana':
|
||||
- indices:admin/create
|
||||
- indices:admin/exists
|
||||
- indices:admin/mapping/put
|
||||
- indices:admin/mappings/fields/get
|
||||
|
|
@ -192,12 +332,5 @@ kibana4_server:
|
|||
- indices:data/write/delete
|
||||
- indices:data/write/index
|
||||
- indices:data/write/update
|
||||
------------------------------------------------------------------------------------------------------------------------
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
To configure the Kibana 4 server, you must assign this role to a user and add the user credentials to `kibana.yml`.
|
||||
For more information, see http://www.elastic.co/guide/en/kibana/current/production.html#configuring-kibana-shield[Configuring Kibana to Work with Shield] in the Kibana 4 User Guide.
|
||||
|
||||
[float]
|
||||
===== Configuring Kibana 4 to Use SSL
|
||||
|
||||
You should also configure Kibana 4 to use SSL encryption for both client requests and the requests the Kibana server sends to Elasticsearch. For more information, see http://www.elastic.co/guide/en/kibana/current/production.html#enabling-ssl[Enabling SSL] in the Kibana 4 User Guide.
|
||||
|
|
|
|||
Loading…
Reference in New Issue