146 lines
6.3 KiB
Plaintext
146 lines
6.3 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:
|
||
|
|
|
||
|
|
* User authentication
|
||
|
|
* Authorization and Role Based Access Control (a.k.a RBAC)
|
||
|
|
* Node/Client Authentication and Channel Encryption
|
||
|
|
* Auditing
|
||
|
|
|
||
|
|
|
||
|
|
[float]
|
||
|
|
=== User Authentication
|
||
|
|
|
||
|
|
User authentication is the process of identifying the users behind the requests
|
||
|
|
that hit the cluster and verifying that indeed they are who they claim to be. The
|
||
|
|
authentication process is handled by one or more authentication services called
|
||
|
|
_realms_. {security} provides the following built-in realms:
|
||
|
|
|
||
|
|
|======
|
||
|
|
| `native` | | | An internal realm where users are stored in a dedicated
|
||
|
|
Elasticsearch index. With this realm, users are
|
||
|
|
authenticated by usernames and passwords. The users
|
||
|
|
are managed via the <<security-api-users,User Management API>>.
|
||
|
|
|
||
|
|
| `ldap` | | | A realm that uses an external LDAP server to authenticate
|
||
|
|
the users. With this realm, users are authenticated by
|
||
|
|
usernames and passwords.
|
||
|
|
|
||
|
|
| `active_directory` | | | A realm that uses an external Active Directory Server
|
||
|
|
to authenticate the users. With this realm, users
|
||
|
|
are authenticated by usernames and passwords.
|
||
|
|
|
||
|
|
| `pki` | | | A realm that authenticates users using Public Key
|
||
|
|
Infrastructure (PKI). This realm works in conjunction
|
||
|
|
with SSL/TLS and identifies the users through the
|
||
|
|
Distinguished Name (DN) of the client's X.509
|
||
|
|
certificates.
|
||
|
|
|
||
|
|
| `file` | | | An internal realm where users are defined in files
|
||
|
|
stored on each node in the Elasticsearch cluster.
|
||
|
|
With this realm, users are authenticated by usernames
|
||
|
|
and passwords. The users are managed via
|
||
|
|
<<managing-file-users,dedicated tools>> that are
|
||
|
|
provided by {xpack} on installation.
|
||
|
|
|======
|
||
|
|
|
||
|
|
If none of the built-in realms meets your needs, you can also build your own
|
||
|
|
custom realm and plug it into {xpack}.
|
||
|
|
|
||
|
|
When {security} is enabled, depending on the realms you've configured, you will
|
||
|
|
need to attach your user credentials to the requests sent to Elasticsearch. For
|
||
|
|
example, when using realms that support usernames and passwords you can simply
|
||
|
|
attach {wikipedia}/Basic_access_authentication[basic auth] header to the requests.
|
||
|
|
|
||
|
|
For more information on user authentication see <<setting-up-authentication>>
|
||
|
|
|
||
|
|
|
||
|
|
[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>>.
|