e92892a174
* [DOCS] Creates separate doc for security in production * Use Kibana attribute * Update CSP section * Move SSL section to the top This is the highest priority item for securing a production installation of Kibana. * Add section on using secure HTTP headers * Write intro * [DOCS] Fixes broken link and other minor edits * [DOCS] Changes man to manipulator Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Joe Portner <5295965+jportner@users.noreply.github.com>
99 lines
3.6 KiB
Text
99 lines
3.6 KiB
Text
[[production]]
|
|
= Use {kib} in a production environment
|
|
|
|
++++
|
|
<titleabbrev>Production considerations</titleabbrev>
|
|
++++
|
|
|
|
How you deploy {kib} largely depends on your use case. If you are the only user,
|
|
you can run {kib} on your local machine and configure it to point to whatever
|
|
{es} instance you want to interact with. Conversely, if you have a large
|
|
number of heavy {kib} users, you might need to load balance across multiple
|
|
{kib} instances that are all connected to the same {es} instance.
|
|
|
|
While {kib} isn't terribly resource intensive, we still recommend running {kib}
|
|
separate from your {es} data or master nodes. To distribute {kib}
|
|
traffic across the nodes in your {es} cluster,
|
|
you can configure {kib} to use a list of {es} hosts.
|
|
|
|
[float]
|
|
[[load-balancing-kibana]]
|
|
=== Load balancing across multiple {kib} instances
|
|
To serve multiple {kib} installations behind a load balancer, you must change the configuration.
|
|
See {kibana-ref}/settings.html[Configuring {kib}] for details on each setting.
|
|
|
|
Settings unique across each {kib} instance:
|
|
[source,js]
|
|
--------
|
|
server.uuid
|
|
server.name
|
|
--------
|
|
|
|
Settings unique across each host (for example, running multiple installations on the same virtual machine):
|
|
[source,js]
|
|
--------
|
|
logging.dest
|
|
path.data
|
|
pid.file
|
|
server.port
|
|
--------
|
|
|
|
Settings that must be the same:
|
|
[source,js]
|
|
--------
|
|
xpack.security.encryptionKey //decrypting session information
|
|
xpack.reporting.encryptionKey //decrypting reports
|
|
xpack.encryptedSavedObjects.encryptionKey // decrypting saved objects
|
|
xpack.encryptedSavedObjects.keyRotation.decryptionOnlyKeys // saved objects encryption key rotation, if any
|
|
--------
|
|
|
|
Separate configuration files can be used from the command line by using the `-c` flag:
|
|
[source,js]
|
|
--------
|
|
bin/kibana -c config/instance1.yml
|
|
bin/kibana -c config/instance2.yml
|
|
--------
|
|
|
|
[float]
|
|
[[accessing-load-balanced-kibana]]
|
|
=== Accessing multiple load-balanced {kib} clusters
|
|
|
|
To access multiple load-balanced {kib} clusters from the same browser,
|
|
set `xpack.security.cookieName` in the configuration.
|
|
This avoids conflicts between cookies from the different {kib} instances.
|
|
|
|
In each cluster, {kib} instances should have the same `cookieName`
|
|
value. This will achieve seamless high availability and keep the session
|
|
active in case of failure from the currently used instance.
|
|
|
|
[float]
|
|
[[high-availability]]
|
|
=== High availability across multiple {es} nodes
|
|
{kib} can be configured to connect to multiple {es} nodes in the same cluster. In situations where a node becomes unavailable,
|
|
{kib} will transparently connect to an available node and continue operating. Requests to available hosts will be routed in a round robin fashion.
|
|
|
|
In kibana.yml:
|
|
[source,js]
|
|
--------
|
|
elasticsearch.hosts:
|
|
- http://elasticsearch1:9200
|
|
- http://elasticsearch2:9200
|
|
--------
|
|
|
|
Related configurations include `elasticsearch.sniffInterval`, `elasticsearch.sniffOnStart`, and `elasticsearch.sniffOnConnectionFault`.
|
|
These can be used to automatically update the list of hosts as a cluster is resized. Parameters can be found on the {kibana-ref}/settings.html[settings page].
|
|
|
|
[float]
|
|
[[memory]]
|
|
=== Memory
|
|
|
|
Kibana has a default memory limit that scales based on total memory available. In some scenarios, such as large reporting jobs,
|
|
it may make sense to tweak limits to meet more specific requirements.
|
|
|
|
A limit can be defined by setting `--max-old-space-size` in the `node.options` config file found inside the `kibana/config` folder or any other folder configured with the environment variable `KBN_PATH_CONF`. For example, in the Debian-based system, the folder is `/etc/kibana`.
|
|
|
|
The option accepts a limit in MB:
|
|
[source,js]
|
|
--------
|
|
--max-old-space-size=2048
|
|
--------
|