elasticsearch/docs/reference/security/security-manual-configuration.asciidoc

[[manually-configure-security]]
== Manually configure security

Security needs vary depending on whether you're developing locally on your
laptop or securing all communications in a production environment. Regardless
of where you're deploying the {stack} ("ELK"), running a secure cluster is
incredibly important to protect your data. That's why security is
<<configuring-stack-security,enabled and configured by default>> in {es} 8.0
and later.

If you want to enable security on an existing, unsecured cluster, use your own 
Certificate Authority (CA), or would rather manually configure security, the 
following scenarios provide steps for configuring TLS on the transport layer,
plus securing HTTPS traffic if you want it.

If you configure security manually _before_ starting your {es} nodes, the
auto-configuration process will respect your security configuration. You can
adjust your TLS configuration at any time, such as 
<<update-node-certs,updating node certificates>>.

image::images/elastic-security-overview.png[Elastic Security layers]

[discrete]
[[security-minimal-overview]]
=== Minimal security ({es} Development)

If you've been working with {es} and want to enable security on your existing,
unsecured cluster, start here. You'll set passwords for the built-in users to prevent 
unauthorized access to your local cluster, and also configure password 
authentication for {kib}.

// tag::minimal-security-note[]
IMPORTANT: The minimal security scenario is not sufficient for
<<dev-vs-prod-mode,production mode>> clusters. If your cluster has multiple
nodes, you must enable minimal security and then
<<security-basic-setup,configure Transport Layer Security (TLS)>> between
nodes.

// end::minimal-security-note[]

<<security-minimal-setup,Set up minimal security>>

[discrete]
[[security-basic-overview]]
=== Basic security ({es} + {kib})

This scenario configures TLS for communication between
nodes. This security layer requires that nodes verify security certificates,
which prevents unauthorized nodes from joining your {es} cluster.

Your external HTTP traffic between {es} and {kib} won't be encrypted, but
internode communication will be secured.

<<security-basic-setup,Set up basic security>>

[discrete]
[[security-basic-https-overview]]
=== Basic security plus secured HTTPS traffic ({stack})

This scenario builds on the one for basic security and secures all HTTP
traffic with TLS. In addition to configuring TLS on the transport interface of
your {es} cluster, you configure TLS on the HTTP interface for both
{es} and {kib}.

NOTE: If you need mutual (bidirectional) TLS on the HTTP layer, then you'll
need to configure mutual authenticated encryption.

You then configure {kib} and Beats to communicate with
{es} using TLS so that all communications are encrypted. This level
of security is strong, and ensures that any communications in and out of your
cluster are secure.

<<security-basic-setup-https,Set up basic security plus HTTPS traffic>>

include::securing-communications/security-minimal-setup.asciidoc[]

include::securing-communications/security-basic-setup.asciidoc[]

include::securing-communications/security-basic-setup-https.asciidoc[]

include::securing-communications/change-passwords-native-users.asciidoc[]

include::securing-communications/enabling-cipher-suites.asciidoc[]

include::securing-communications/tls-versions-jdk.asciidoc[]

include::reference/files.asciidoc[]

include::fips-140-compliance.asciidoc[]