WARNING: Version 5.4 of the Elastic Stack has passed its EOL date.

This documentation is no longer being maintained and may be removed. If you are running this version, we strongly advise you to upgrade. For the latest information, see the current release documentation.

« Getting Started with Security Setting Up User Authentication »

› ›

How Security Works

edit

How Security Works

edit

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.

X-Pack 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

User Authentication

edit

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. X-Pack 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 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 dedicated tools that are provided by X-Pack on installation.

If none of the built-in realms meets your needs, you can also build your own custom realm and plug it into X-Pack.

When X-Pack 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 basic auth header to the requests.

For more information on user authentication see Setting Up User Authentication

Authorization

edit

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 Configuring Role-based Access Control

Node/Client Authentication and Channel Encryption

edit

X-Pack 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.

X-Pack security also enables you to 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.

Auditing

edit

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).

X-Pack 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 Security Events.

« Getting Started with Security Setting Up User Authentication »