mirror of
https://github.com/elastic/elasticsearch.git
synced 2025-04-24 23:27:25 -04:00
255c9a7f95
**Problem:** For historical reasons, source files for the Elasticsearch Guide's security, watcher, and Logstash API docs are housed in the `x-pack/docs` directory. This can confuse new contributors who expect Elasticsearch Guide docs to be located in `docs/reference`. **Solution:** - Move the security, watcher, and Logstash API doc source files to the `docs/reference` directory - Update doc snippet tests to use security Rel: https://github.com/elastic/platform-docs-team/issues/208
54 lines
No EOL
2.7 KiB
Text
54 lines
No EOL
2.7 KiB
Text
[[es-security-principles]]
|
|
== {es} security principles
|
|
Protecting your {es} cluster and the data it contains is of utmost importance.
|
|
Implementing a defense in depth strategy provides multiple layers of security
|
|
to help safeguard your system. The following principles provide a foundation
|
|
for running {es} in a secure manner that helps to mitigate attacks on your
|
|
system at multiple levels.
|
|
|
|
[discrete]
|
|
[[security-run-with-security]]
|
|
=== Run {es} with security enabled
|
|
Never run an {es} cluster without security enabled. This principle cannot be
|
|
overstated. Running {es} without security leaves your cluster exposed to anyone
|
|
who can send network traffic to {es}, permitting these individuals to download,
|
|
modify, or delete any data in your cluster.
|
|
<<configuring-stack-security,Start the {stack} with security enabled>> or
|
|
<<manually-configure-security,manually configure security>> to prevent
|
|
unauthorized access to your clusters and ensure that internode communication
|
|
is secure.
|
|
|
|
[discrete]
|
|
[[security-not-root-user]]
|
|
=== Run {es} with a dedicated non-root user
|
|
Never try to run {es} as the `root` user, which would invalidate any defense
|
|
strategy and permit a malicious user to do *anything* on your server. You must
|
|
create a dedicated, unprivileged user to run {es}. By default, the `rpm`, `deb`,
|
|
`docker`, and Windows packages of {es} contain an `elasticsearch` user with
|
|
this scope.
|
|
|
|
[discrete]
|
|
[[security-protect-cluster-traffic]]
|
|
=== Protect {es} from public internet traffic
|
|
Even with security enabled, never expose {es} to public internet traffic.
|
|
Using an application to sanitize requests to {es} still poses risks, such as
|
|
a malicious user writing <<search,`_search`>> requests that could overwhelm an
|
|
{es} cluster and bring it down. Keep {es} as isolated as possible, preferably
|
|
behind a firewall and a VPN. Any internet-facing applications should run
|
|
pre-canned aggregations, or not run aggregations at all.
|
|
|
|
While you absolutely shouldn't expose {es} directly to the internet, you also
|
|
shouldn't expose {es} directly to users. Instead, use an intermediary
|
|
application to make requests on behalf of users. This implementation allows you
|
|
to track user behaviors, such as can submit requests, and to which specific
|
|
nodes in the cluster. For example, you can implement an application that accepts
|
|
a search term from a user and funnels it through a
|
|
<<query-dsl-simple-query-string-query,`simple_query_string`>> query.
|
|
|
|
[discrete]
|
|
[[security-create-appropriate-users]]
|
|
=== Implement role based access control
|
|
<<defining-roles,Define roles>> for your users and
|
|
<<security-privileges,assign appropriate privileges>> to ensure that users have
|
|
access only to the resources that they need. This process determines whether the
|
|
user behind an incoming request is allowed to run that request. |