OpenSearch/x-pack/docs/en/security/how-security-works.asciidoc

[[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
                            {ref}/security-api-users.html[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 {xpack} on installation.

| `saml`              | | | A realm that uses SAML 2.0 Web SSO. This realm is
                            designed to be used with {kib}.
|======

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