98 lines
3.9 KiB
Plaintext
98 lines
3.9 KiB
Plaintext
[[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 an clients, all communicating with the it.
|
|
It should not come as a surprise that securing such clusters has many facets and
|
|
layers.
|
|
|
|
{security} provides the means to secure the Elastic cluster on several levels:
|
|
|
|
* <<setting-up-authentication>>
|
|
* Authorization and Role Based Access Control (a.k.a RBAC)
|
|
* Node/Client Authentication and Channel Encryption
|
|
* Auditing
|
|
|
|
[float]
|
|
=== Authorization
|
|
|
|
The authorization process takes place once a request is authenticated and the
|
|
User behind the request is identified. Authorization is the process of determining
|
|
whether the user behind an incoming request is allowed to execute it. Naturally,
|
|
this process takes place right after an successful authentication - when the
|
|
user identity is known.
|
|
|
|
The authorization process revolves around the following 5 constructs:
|
|
|
|
_Secured Resource_::
|
|
A resource to which access is restricted. Indices/aliases, documents, fields,
|
|
users and the Elasticsearch cluster itself are all examples of secured objects.
|
|
|
|
_Privilege_::
|
|
A named group representing one or more actions that a user may execute against a
|
|
secured resource. Each secured resource has its own sets of available privileges.
|
|
For example, `read` is an index privilege that represents all actions that enable
|
|
reading the indexed/stored data. For a complete list of available privileges
|
|
see <<security-privileges>>.
|
|
|
|
_Permissions_::
|
|
A set of one or more privileges against a secured resource. Permissions can
|
|
easily be described in words, here are few examples:
|
|
* `read` privilege on the `products` index
|
|
* `manage` privilege on the cluster
|
|
* `run_as` privilege on `john` user
|
|
* `read` privilege on documents that match query X
|
|
* `read` privilege on `credit_card` field
|
|
|
|
_Role_::
|
|
A named sets of permissions
|
|
|
|
_User_::
|
|
The authenticated user.
|
|
|
|
A secure Elasticsearch cluster manages the privileges of users through _roles_.
|
|
A role has a unique name and identifies a set of permissions that translate to
|
|
privileges on resources. A user can be associated with an arbitrary number of
|
|
roles. The total set of permissions that a user has is therefore defined by
|
|
union of the permissions in all its roles.
|
|
|
|
Roles can be assigned to users in a number of ways depending on the realms by
|
|
which the users are authenticated.
|
|
|
|
For more information on user authentication see <<authorization>>
|
|
|
|
|
|
[float]
|
|
=== Node/Client Authentication and Channel Encryption
|
|
|
|
{security} supports 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>>.
|
|
|
|
{security} also enables 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).
|
|
|
|
{security} provides 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>>.
|