[DOCS] Add security section to Elasticsearch book (#46883)
Co-Authored-By: Tim Vernum <tim@adjective.org>
This commit is contained in:
parent
99130114de
commit
4c688df0ef
|
@ -20,8 +20,6 @@ include::setup/setup-xes.asciidoc[]
|
||||||
|
|
||||||
include::monitoring/configuring-monitoring.asciidoc[]
|
include::monitoring/configuring-monitoring.asciidoc[]
|
||||||
|
|
||||||
include::{xes-repo-dir}/security/configuring-es.asciidoc[]
|
|
||||||
|
|
||||||
include::setup/setup-xclient.asciidoc[]
|
include::setup/setup-xclient.asciidoc[]
|
||||||
|
|
||||||
include::setup/bootstrap-checks-xes.asciidoc[]
|
include::setup/bootstrap-checks-xes.asciidoc[]
|
||||||
|
@ -58,6 +56,8 @@ include::frozen-indices.asciidoc[]
|
||||||
|
|
||||||
include::high-availability.asciidoc[]
|
include::high-availability.asciidoc[]
|
||||||
|
|
||||||
|
include::security/index.asciidoc[]
|
||||||
|
|
||||||
include::commands/index.asciidoc[]
|
include::commands/index.asciidoc[]
|
||||||
|
|
||||||
include::how-to.asciidoc[]
|
include::how-to.asciidoc[]
|
||||||
|
|
|
@ -0,0 +1,18 @@
|
||||||
|
[[secure-cluster]]
|
||||||
|
= Secure a cluster
|
||||||
|
|
||||||
|
[partintro]
|
||||||
|
--
|
||||||
|
The {stack-security-features} enable you to easily secure a cluster. You can
|
||||||
|
password-protect your data as well as implement more advanced security
|
||||||
|
measures such as encrypting communications, role-based access control,
|
||||||
|
IP filtering, and auditing.
|
||||||
|
|
||||||
|
* <<elasticsearch-security>>
|
||||||
|
* <<configuring-security>>
|
||||||
|
|
||||||
|
--
|
||||||
|
|
||||||
|
include::overview.asciidoc[]
|
||||||
|
|
||||||
|
include::{xes-repo-dir}/security/configuring-es.asciidoc[]
|
|
@ -0,0 +1,63 @@
|
||||||
|
[role="xpack"]
|
||||||
|
[[elasticsearch-security]]
|
||||||
|
== Security overview
|
||||||
|
++++
|
||||||
|
<titleabbrev>Overview</titleabbrev>
|
||||||
|
++++
|
||||||
|
|
||||||
|
Security protects {es} clusters by:
|
||||||
|
|
||||||
|
* <<preventing-unauthorized-access, Preventing unauthorized access>>
|
||||||
|
with password protection, role-based access control, and IP filtering.
|
||||||
|
* <<preserving-data-integrity, Preserving the integrity of your data>>
|
||||||
|
with SSL/TLS encryption.
|
||||||
|
* <<maintaining-audit-trail, Maintaining an audit trail>>
|
||||||
|
so you know who's doing what to your cluster and the data it stores.
|
||||||
|
|
||||||
|
[float]
|
||||||
|
[[preventing-unauthorized-access]]
|
||||||
|
=== Preventing unauthorized access
|
||||||
|
|
||||||
|
To prevent unauthorized access to your {es} cluster, you must have a
|
||||||
|
way to _authenticate_ users. This simply means that you need a way to validate
|
||||||
|
that a user is who they claim to be. For example, you have to make sure only
|
||||||
|
the person named _Kelsey Andorra_ can sign in as the user `kandorra`. The
|
||||||
|
{es-security-features} provide a standalone authentication mechanism that enables
|
||||||
|
you to quickly password-protect your cluster. If you're already using LDAP,
|
||||||
|
Active Directory, or PKI to manage users in your organization, the
|
||||||
|
{security-features} are able to integrate with those systems to perform user
|
||||||
|
authentication.
|
||||||
|
|
||||||
|
In many cases, simply authenticating users isn't enough. You also need a way to
|
||||||
|
control what data users have access to and what tasks they can perform. The
|
||||||
|
{es-security-features} enable you to _authorize_ users by assigning access
|
||||||
|
_privileges_ to _roles_ and assigning those roles to users. For example, this
|
||||||
|
role-based access control mechanism (a.k.a RBAC) enables you to specify that the
|
||||||
|
user `kandorra` can only perform read operations on the `events` index and can't
|
||||||
|
do anything at all with other indices.
|
||||||
|
|
||||||
|
The {security-features} also support IP-based authorization.
|
||||||
|
You can whitelist and blacklist specific IP addresses or subnets to control
|
||||||
|
network-level access to a server.
|
||||||
|
|
||||||
|
[float]
|
||||||
|
[[preserving-data-integrity]]
|
||||||
|
=== Preserving data integrity
|
||||||
|
|
||||||
|
A critical part of security is keeping confidential data confidential.
|
||||||
|
{es} has built-in protections against accidental data loss and
|
||||||
|
corruption. However, there's nothing to stop deliberate tampering or data
|
||||||
|
interception. The {stack-security-features} preserve the integrity of your
|
||||||
|
data by encrypting communications to and from nodes. For even
|
||||||
|
greater protection, you can increase the <<ciphers,encryption strength>>.
|
||||||
|
|
||||||
|
[float]
|
||||||
|
[[maintaining-audit-trail]]
|
||||||
|
=== Maintaining an audit trail
|
||||||
|
|
||||||
|
Keeping a system secure takes vigilance. By using {stack-security-features} to
|
||||||
|
maintain an audit trail, you can easily see who is accessing your cluster and
|
||||||
|
what they're doing. By analyzing access patterns and failed attempts to access
|
||||||
|
your cluster, you can gain insights into attempted attacks and data breaches.
|
||||||
|
Keeping an auditable log of the activity in your cluster can also help diagnose
|
||||||
|
operational issues.
|
Loading…
Reference in New Issue