51 lines
2.1 KiB
Plaintext
51 lines
2.1 KiB
Plaintext
|
[role="xpack"]
|
||
|
|
[[how-security-works]]
|
||
|
|
== How security works
|
||
|
|
|
||
|
|
An Elasticsearch cluster is typically made out of many moving parts. There are
|
||
|
|
the Elasticsearch nodes that form the cluster and often Logstash instances,
|
||
|
|
Kibana instances, Beats agents, and clients all communicating with the cluster.
|
||
|
|
It should not come as a surprise that securing such clusters has many facets and
|
||
|
|
layers.
|
||
|
|
|
||
|
|
The {stack-security-features} provide the means to secure the Elastic cluster
|
||
|
|
on several levels:
|
||
|
|
|
||
|
|
* <<setting-up-authentication,User authentication>>
|
||
|
|
* <<authorization,User authorization and access control>>
|
||
|
|
* Node/client authentication and channel encryption
|
||
|
|
* Auditing
|
||
|
|
|
||
|
|
[float]
|
||
|
|
=== Node/client authentication and channel encryption
|
||
|
|
|
||
|
|
The {security-features} support configuring SSL/TLS for securing the
|
||
|
|
communication channels to, from and within the cluster. This support accounts for:
|
||
|
|
|
||
|
|
* Encryption of data transmitted over the wires
|
||
|
|
* Certificate based node authentication - preventing unauthorized nodes/clients
|
||
|
|
from establishing a connection with the cluster.
|
||
|
|
|
||
|
|
For more information, see <<encrypting-communications, Encrypting Communications>>.
|
||
|
|
|
||
|
|
The {security-features} also enable you to <<ip-filtering, configure IP Filters>>
|
||
|
|
which can be seen as a light mechanism for node/client authentication. With IP
|
||
|
|
filtering, you can restrict the nodes and clients that can connect to the
|
||
|
|
cluster based on their IP addresses. The IP filters configuration provides
|
||
|
|
whitelisting and blacklisting of IPs, subnets and DNS domains.
|
||
|
|
|
||
|
|
|
||
|
|
[float]
|
||
|
|
=== Auditing
|
||
|
|
When dealing with any secure system, it is critical to have a audit trail
|
||
|
|
mechanism set in place. Audit trails log various activities/events that occur in
|
||
|
|
the system, enabling you to analyze and back track past events when things go
|
||
|
|
wrong (e.g. security breach).
|
||
|
|
|
||
|
|
The {security-features} provide such audit trail functionality for all nodes in
|
||
|
|
the cluster. You can configure the audit level which accounts for the type of
|
||
|
|
events that are logged. These events include failed authentication attempts,
|
||
|
|
user access denied, node connection denied, and more.
|
||
|
|
|
||
|
|
For more information on auditing see <<auditing>>.
|