mirror of
https://github.com/elastic/kibana.git
synced 2025-04-22 08:49:27 -04:00
652f4bb49b
A content security policy is a great addition to the protections built into Kibana, but it's not effective in older browsers (like IE11) that do not enforce the policy. When CSP strict mode is enabled, right before the Kibana app is bootstrapped, a basic safety check is performed to see if "naked" inline scripts are rejected. If inline scripting is allowed by the browser, then an error message is presented to the user and Kibana never attempts to bootstrap.
111 lines
4.4 KiB
Text
111 lines
4.4 KiB
Text
[[production]]
|
|
== Using Kibana in a production environment
|
|
|
|
* <<configuring-kibana-shield>>
|
|
* <<csp-strict-mode>>
|
|
* <<enabling-ssl>>
|
|
* <<load-balancing>>
|
|
|
|
How you deploy Kibana largely depends on your use case. If you are the only user,
|
|
you can run Kibana on your local machine and configure it to point to whatever
|
|
Elasticsearch instance you want to interact with. Conversely, if you have a large
|
|
number of heavy Kibana users, you might need to load balance across multiple
|
|
Kibana instances that are all connected to the same Elasticsearch instance.
|
|
|
|
While Kibana isn't terribly resource intensive, we still recommend running Kibana
|
|
separate from your Elasticsearch data or master nodes. To distribute Kibana
|
|
traffic across the nodes in your Elasticsearch cluster, you can run Kibana
|
|
and an Elasticsearch client node on the same machine. For more information, see
|
|
<<load-balancing, Load Balancing Across Multiple Elasticsearch Nodes>>.
|
|
|
|
[float]
|
|
[[configuring-kibana-shield]]
|
|
=== Using {stack} {security-features}
|
|
|
|
You can use {stack-ov}/elasticsearch-security.html[{stack} {security-features}]
|
|
to control what {es} data users can access through Kibana.
|
|
|
|
When {security-features} are enabled, Kibana users have to log in. They need to
|
|
have the `kibana_user` role as well as access to the indices they
|
|
will be working with in Kibana.
|
|
|
|
If a user loads a Kibana dashboard that accesses data in an index that they
|
|
are not authorized to view, they get an error that indicates the index does
|
|
not exist. The {security-features} do not currently provide a way to control
|
|
which users can load which dashboards.
|
|
|
|
For information about setting up Kibana users, see
|
|
{kibana-ref}/using-kibana-with-security.html[Configuring security in Kibana].
|
|
|
|
[float]
|
|
[[csp-strict-mode]]
|
|
=== Require Content Security Policy
|
|
|
|
Kibana uses a Content Security Policy to help prevent the browser from allowing
|
|
unsafe scripting, but older browsers will silently ignore this policy. If your
|
|
organization does not need to support Internet Explorer 11 or much older
|
|
versions of our other supported browsers, we recommend that you enable Kibana's
|
|
`strict` mode for content security policy, which will block access to Kibana
|
|
for any browser that does not enforce even a rudimentary set of CSP
|
|
protections.
|
|
|
|
To do this, set `csp.strict` to `true` in your `kibana.yml`:
|
|
|
|
--------
|
|
csp.strict: true
|
|
--------
|
|
|
|
|
|
[float]
|
|
[[enabling-ssl]]
|
|
=== Enabling SSL
|
|
|
|
See <<configuring-tls>>.
|
|
|
|
[float]
|
|
[[load-balancing]]
|
|
=== Load Balancing Across Multiple Elasticsearch Nodes
|
|
If you have multiple nodes in your Elasticsearch cluster, the easiest way to distribute Kibana requests
|
|
across the nodes is to run an Elasticsearch _Coordinating only_ node on the same machine as Kibana.
|
|
Elasticsearch Coordinating only nodes are essentially smart load balancers that are part of the cluster. They
|
|
process incoming HTTP requests, redirect operations to the other nodes in the cluster as needed, and
|
|
gather and return the results. For more information, see
|
|
{ref}/modules-node.html[Node] in the Elasticsearch reference.
|
|
|
|
To use a local client node to load balance Kibana requests:
|
|
|
|
. Install Elasticsearch on the same machine as Kibana.
|
|
. Configure the node as a Coordinating only node. In `elasticsearch.yml`, set `node.data`, `node.master` and `node.ingest` to `false`:
|
|
+
|
|
--------
|
|
# 3. You want this node to be neither master nor data node nor ingest node, but
|
|
# to act as a "search load balancer" (fetching data from nodes,
|
|
# aggregating results, etc.)
|
|
#
|
|
node.master: false
|
|
node.data: false
|
|
node.ingest: false
|
|
--------
|
|
. Configure the client node to join your Elasticsearch cluster. In `elasticsearch.yml`, set the `cluster.name` to the
|
|
name of your cluster.
|
|
+
|
|
--------
|
|
cluster.name: "my_cluster"
|
|
--------
|
|
. Check your transport and HTTP host configs in `elasticsearch.yml` under `network.host` and `transport.host`. The `transport.host` needs to be on the network reachable to the cluster members, the `network.host` is the network for the HTTP connection for Kibana (localhost:9200 by default).
|
|
+
|
|
--------
|
|
network.host: localhost
|
|
http.port: 9200
|
|
|
|
# by default transport.host refers to network.host
|
|
transport.host: <external ip>
|
|
transport.tcp.port: 9300 - 9400
|
|
--------
|
|
. Make sure Kibana is configured to point to your local client node. In `kibana.yml`, the `elasticsearch.hosts` setting should be set to
|
|
`["localhost:9200"]`.
|
|
+
|
|
--------
|
|
# The Elasticsearch instance to use for all your queries.
|
|
elasticsearch.hosts: ["http://localhost:9200"]
|
|
--------
|