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>
88 lines
3 KiB
Text
88 lines
3 KiB
Text
[role="xpack"]
|
|
[[Security-production-considerations]]
|
|
== Security production considerations
|
|
|
|
++++
|
|
<titleabbrev>Security</titleabbrev>
|
|
++++
|
|
:keywords: administrator, analyst, concept, setup, security
|
|
:description: Consider the production components for {kib} security.
|
|
|
|
To secure your {kib} installation in production, consider these high-priority topics to ensure
|
|
that only authorized users can access {kib}.
|
|
For more information on {kib}'s security controls, see <<using-kibana-with-security, Configure security>>.
|
|
|
|
[float]
|
|
[[enabling-ssl]]
|
|
=== Enable SSL/TLS
|
|
|
|
You should use SSL/TLS encryption to ensure that traffic between browsers and the {kib} server cannot be viewed or tampered with by third
|
|
parties. See <<configuring-tls>>.
|
|
|
|
[float]
|
|
[[configuring-kibana-shield]]
|
|
=== Use {stack} {security-features}
|
|
|
|
You can use {stack} {security-features} to control what {es} data users can
|
|
access through {kib}.
|
|
|
|
When {security-features} are enabled, {kib} users have to log in. They must
|
|
have a role granting <<kibana-privileges, {kib} privileges>> and access
|
|
to the indices that they will be working with in {kib}.
|
|
|
|
If a user loads a {kib} 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.
|
|
|
|
For more information on granting access to {kib}, see <<xpack-security-authorization>>.
|
|
|
|
[float]
|
|
[[configuring-security-headers]]
|
|
=== Use secure HTTP headers
|
|
|
|
The {kib} server can instruct browsers to enable additional security controls using HTTP headers.
|
|
|
|
1. Enable HTTP Strict-Transport-Security.
|
|
+
|
|
Use <<server-securityResponseHeaders-strictTransportSecurity,`strictTransportSecurity`>> to ensure that browsers will only attempt
|
|
to access {kib} with SSL/TLS encryption. This is designed to prevent manipulator-in-the-middle attacks.
|
|
To configure this with a lifetime of one
|
|
year in your `kibana.yml`:
|
|
+
|
|
[source,js]
|
|
--------
|
|
server.securityResponseHeaders.strictTransportSecurity: "max-age=31536000"
|
|
--------
|
|
+
|
|
WARNING: This header will block unencrypted connections for the entire domain. If you host more than one web application on the same domain
|
|
using different ports or paths, all of them will be affected.
|
|
|
|
2. Disable embedding.
|
|
+
|
|
Use <<server-securityResponseHeaders-disableEmbedding, `disableEmbedding`>> to ensure
|
|
that {kib} cannot be embedded in other websites.
|
|
To configure this in your `kibana.yml`:
|
|
+
|
|
[source,js]
|
|
--------
|
|
server.securityResponseHeaders.disableEmbedding: true
|
|
--------
|
|
|
|
[float]
|
|
[[csp-strict-mode]]
|
|
=== Require a Content Security Policy
|
|
|
|
{kib} uses a Content Security Policy (CSP) to prevent the browser from allowing
|
|
unsafe scripting, but older browsers will silently ignore this policy. If your
|
|
organization does not need to support very old
|
|
versions of our supported browsers, we recommend that you enable {kib}'s
|
|
`strict` mode for the CSP. This will block access to {kib}
|
|
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`:
|
|
|
|
[source,js]
|
|
--------
|
|
csp.strict: true
|
|
--------
|